Martin Scotta
On Thu, Apr 28, 2011 at 2:51 PM, Matt Wilson <sha...@gmail.com> wrote:
> 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.
>
Probably core folks may know how this works better than me but I think that
null is not an object, scalar or anything at all. It just means
the absence of value.
That's why I always thought that NULL meant "no value".
function foo(Foo $f1, Foo $f2=null) {
// $f1 can't be null
// $f2 can be null
}
> 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
>
>
