Re: [RFC] Alternative typehinting syntax for accessors

From: 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.

« previous php.internals (#64585) next »