Re: [RFC] Alternative typehinting syntax for accessors
| From: | Nikita Popov | Date: | Sun, 06 Jan 2013 00:41:34 +0000 |
| Subject: | Re: [RFC] Alternative typehinting syntax for accessors | ||
| References: | 1 2 3 4 5 6 7 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-64585@lists.php.net to get a copy of this message | ||
On Sun, Jan 6, 2013 at 1:18 AM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:
> Hi!
>
> > "Too much magic"? It's completely consistent with how method parameters
> > work now. In fact, I'd argue that introducing a new syntax for this
> > would be inconsistent with the current paradigm.
>
> But this in for methods, and you are putting it into entirely different
> place - property initializer. That's what I call magic - somehow
> property initializer magically becomes method parameter's default value.
>
> > This becomes especially true if initializers are added, where the
> > property would be initialized to a non-null value. Hence adding the
> > ability for it to *never* actually *be* null in the first place...
>
> I think property initializers won't work well, especially combined with
> this syntax. What should public DateTime $foo = 42; produce?
>
Consider the normal function typehints:
function foo(DateTime $foo = 42).
Same problem, same solution. You can only assign "compatible" types. For
object typehints NULL is the only compatible compile-time value. For array
typehints arrays can be used as initializers.
> Essentially it looks like the only initializer useful here would be
> NULL. In this case, why not just make it simple and always allow NULL
> there and get rid of the confusing syntax?
Again, same for function typehints. NULL is the only possible initializer
there, too. But still we don't take that as a reason to always allow NULL
for them.
You'd have to allow NULL anyway since otherwise you'd be unable to
> implement unset() and won't
> have any useful isset().
Not every property needs the ability to be unset(). Not being able to unset
it is a feature actually. It guarantees that it will always be available
(after the initial set) and does not have to be checked.
In fact, initial value of any object property
> will always be NULL, so not allowing NULL is pointless as there's always
> NULL there when you start.
>
The timeframe in which it is NULL is usually contained to the constructor.