On Sun, Jan 6, 2013 at 1:18 AM, Stas Malyshev <smalys...@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.
