Right, that's what null means. The difference in php is only in implementation
-- you actually just made my point :)
The only reason to have explicit null hints is if you get hung up on the whole
issue of how php actually implements NULL. The concept is "non value", distinct
from "empty". The implementation in php is slightly difference, since you're
not actually working with, say, a null pointer.
On Apr 28, 2011, at 1:05 PM, Martin Scotta wrote:
>
> 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
>
>
