Stas,
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.
The same could be used to justify the param order difference between
strings and arrays "But these are arrays, they are entirely different"...
> > 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?
>
A compile time fatal error. If it's typed, the only values allowed are the
type and null (in the initializer)
> 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? You'd have to allow NULL
> anyway since otherwise you'd be unable to implement unset() and won't
> have any useful isset(). 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.
>
No, the other initializer that would be useful is `new Foo`. Assigning a
default value is not an initializer. An initializer is something that's run
on object construction (and has been discussed in other threads):
class Foo {
public DateTime $bar {
init: { $bar = new DateTime(); }
}
}
As far as "why not just make it always allow null" is that it half defeats
the point of typed accessors in the first place. Java has huge issues with
null pointers. And if you set the property in the constructor (and it's
typed), you should never have the chance for it to be non-null, unless you
explicitly define it that way. Otherwise, you'd have to litter your code
with is_null checks... Which defeats the point of the syntax in the first
place. Sure, there are going to be use-cases for supporting null. But there
are also plenty of use-cases for explicitly Not allowing null. In fact, I'd
argue that the "not allow null" use-cases are the most frequent and most
critical ones...
Anthony
