Here's my issue: We're borrowing a feature from strongly typed languages and forcing it on a loosely typed language. I'm fine with this, if we're true to the concept.
In a regular language, if you type something to return an object of type Foo, you might still get back null, and appropriately need to check for this. NULL is a perfectly valid state for an object. The objection I'm hearing to this is that because in PHP, null is a value and not a state, and since variables don't have types (values do), null should be an explicitly specified hint. To me, this is a nuclear bomb waiting to go off. If we allow the syntax described earlier (Foo | Bar | Null) we're violating the concept entirely, and there's no point in even having the feature. If a developer can type hint a function in such a way that you don't actually know what you're getting besides a subset of types, this has the exact opposite effect that return hinting is supposed to have. Now, I have to check for what type the value returned is, on top of null. Why even use return hinting? The other suggestion I've heard is to only allow for Object || Null, but this too seems ridiculous. The idea would be that if you're in a situation where you can't feasibly return the specified object, you should throw an exception. So now your code is going to be riddled with things like ObjectIsNullException, or generic handlers that don't know what to do besides go "OOPS!" when this happens. OR, you force default values down your object's throats. This is bad when the object you're using is volatile, and writes to a database or something. The complain is that implicitly allowing null returns means you have to check for null even if you're expecting an object. But *you have to do this anyway* if you're not hinting. +1 for return type hinting -1 for explicitly specifying null -100000000 for specifying multiple return types On Apr 28, 2011, at 12:36 PM, Stas Malyshev wrote: > Hi! > >> There will also be advantages for HipHop which can afford to spend the time >> to >> do static analysis of code -- I know that HipHop is not your baby >> but you now need to recognise that there is more than one PHP implementation >> and features that may not had much advantage with Zend may be useful >> elsewhere. > > If you want a statically typed language, there are tons of these on the > market. However, unless you change PHP into another - statically typed - > language, I do not see how it really helps. > What you talking about here is creating a dialect of PHP targeted for > statically-compiled environment. I personally see it a bit pointless, since > there are already many perfectly good static languages on the market, with > excellent compilers and environments - so why not use any of these? But that > shouldn't deter you - my personal opinion is just that, if you want to create > your own static PHP, go ahead. But I do not believe doing it in little tweaks > would work - if you want reliable typing, you need it everywhere. > > However, I seriously doubt PHP as a whole would benefit from it. Most uses of > PHP are very dynamic and would not yield serious benefits from introducing > static typing constructs beyond very specific cases in very specific > environments. Changing the whole language to benefit these narrow scenarios > does not seem beneficial to me. > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
