2009/1/17 Nathan Rixham <nrixham@xxxxxxxxx>: > Tony Marston wrote: >> >> "Nathan Rixham" <nrixham@xxxxxxxxx> wrote in message >>> >>> a: Optional Static Typing >>> I'm finding an ever increasingly need to be able to staticly type >>> properties, parameters, return types etc (in classes) I know there is type >>> hinting but it's just not enough to do what one needs. Additionally support >>> for staticly typing primatives. Here's an example: >> >> If you really *need* to used a staticly typed language then don't use PHP, >> and don't try to change PHP to match your needs. > > why not? php fills 95% of my needs in most instances, I'm as much a valid > user of php as you and php *could* change to fit my needs and others, not > without some appreciated work mind you, but it could (and without affecting > anybody else in this case) You may think it's a simple need but it has consequences for all users of PHP. You may be able to implement typed variables while still allowing untyped, but it will impact performance at the very least, probably more. > it's a simple need: if I can type that my variable can only contain an int, > then I know it's always an int without tonnes of checks to check it actually > contains an int / is getting set with an int throughout the rest of the app > (especially when multiple dev's are working on it). I would argue that what you have is a want based on your current implementation strategy, rather than a "need". I've never come across any situation where static types would make my code more secure. If your code can't control what you're putting into variables then you have bigger problems than the 5% of your "needs" PHP doesn't meet. Any data coming from the user would need the same amount of validation regardless of whether you were stuffing it into untyped or typed variables. IMHO the same goes for any uncontrolled inputs to isolated code regardless of whether it's expected to be reused or not. > additionally this functionality would open the door to the creation of a lot > more apps and frameworks, not least the ability to create decent ORM's. > Further, it would allow people to contribute proper developers classes that > can be re-used time and time again (for instance a full set of collections > [class, hashmap, map, list, set etc etc]). Once they're made and open source > we all benefit, not only that but they could be made by users instead of the > internals team ;) I really don't see why typed variables would make implementing anything easier or the result better. And IMHO a data structure class (hashmap, map, list, etc) would be far more useful if it could contain any type of variable rather than having to have a different subclass for each type. Or are you thinking PHP should also support templates?!! >>> b: Object superclass >>> A base class type which all objects automagically extend, with (if >>> nothing else) a unique id / hashcode for each object (much like the Java >>> Object class). Failing this some form of function to get a unique reference >>> string for any variable. Example >> >> Why should each class automaticaly extend a base class? For what purpose? >> For what benefit? I can achieve what I want without this *feature*, so I >> don't need it. > > 2 reasons: > 1: it would allow all objects to have this uniqueid/hashcode i need Really don't see why this is necessary. Please elaborate on why you want this? > 2: it would allow one to type hint Object in methods (you currently can't) - > you can method(array $var) but not method(object $var) see: <snip code> I mean no offence, but personally I think this is wanted by "lazy" programmers. It's *you* calling the function so *you* should know what you're giving it. Equally the function should validate what it's been given if it's possible it might not get what it's expecting or it will be used by idiots. >> Why does each object need a unique id/hashcode? I have been using objects >> for years without this so it is not necessary, and does not provide any >> additional functionality. > > for comparison of equality, so you can make indexed arrays quickly using the > hashcode (you know like a hash table) so you can quickly tell the difference > between two instances of the same object with the same values that are > infact different, makes persisting data a 100 times easier... If you need this functionality why not create a member variable in the constructor containing sha1(microtime(true)). However, exposing PHP's internal ID is unlikely to cause BC issues so might be worth requesting on the internals list. It's possible there's already a way to get it, we just don't know about it. >> Why do you need a unique reference string for each variable? WTF! > > well because $a = 's'; $b = 's'; both are unique, internally php must hold a > reference of some sort to each variable and where it's stored that is > entirely unique; it would simply be a case of exposing this functionality > /or/ adding functionality based on this. > >>> c: Method overloading >>> TBH it's something I could live without, whereas a/b aren't, but it would >>> be an ideal addition to php? >> >> PHP does not need method overloading as is found in other languages as it >> has optional parameters with defaults. It is also possible to cast each >> parameter into wahetever type is necessary. It achieves the same result but >> using a different method. > > the same functionality can be achieved, however not without a lot of > additional code to test variable types using conditional blocks with lots of > is_ and instanceof comparisons; adding method overloading is by no means > needed but would majorly simplify the code of scripts which need this > functionality. You can't have both method overloading and variable argument lists - they're just not compatible. You can simulate overloading by putting the common code into a private method and having several differently named public methods that all use the private method. Alternatively you can use variable arguments to get around it. Either way I definitely prefer support for variable and undefined arguments than overloading. >> Absolute rubbish! You have obviously been used to a different language and >> have recently moved to PHP, but cannot get used to the fact that it *IS* a >> different language, therefore it has different syntax and achieves similar >> things in different ways. If your feeble brain can't handle the differences >> then I suggest you stick with your previous language and LEAVE PHP ALONE! > > actually I've been a senior php dev for 5 years and muddled along trying to > help people out on this list for a long time too - it is my primary > language, PHP always changes and the beauty of the language is that it tries > to allow people to program the way they want, hence it being both procedural > and object orientated, obviously there's a need for this otherwise Type > Hinting would never have been introduced. Type hinting is the happy medium between untyped and strongly typed variables. Also, PHP is procedural with OO capabilities due to its history and the engine developers commitment to maintaining backwards compatibility whenever possible. > PHP could easily be a one for all language and AFAIK the only major > functionality missing is static typing..? I'm not trying to knock PHP, > simply expand it's functionality and scope by having additional *optional* > functionality implemented - like namespaces, if you don't like 'em don't use > 'em. Namespaces have a distinct and discrete advantage for all PHP users... they will allow code to insure against naming clashes. All IMHO - PHP FTW!! -Stuart -- http://stut.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
