On Wed, 19 Sep 2018 at 16:57, Levi Morrison <le...@php.net> wrote:
> I posit that this code:
>
> class Foo {
> public Foo $foo;
> }
>
> Is superior to this code:
>
> class Foo {
> public ?Foo $foo = null;
> }
>
> If after "initialization" that `$foo` is guaranteed to always contain
> an object of type `Foo`.
Yes, IF it guaranteed; but the current proposal offers no such guarantee.
Whichever of those definitions is used, the following code may fail:
function expectsFoo(Foo $foo) {
assert($foo->foo instanceOf Foo);
}
> The reason is simple: for the actual lifetime
> of the object the former correctly states that it will never be null,
> while the latter opens up possibilities of it.
It correctly states that it will never be null, but it incorrectly implies
that it will always be an instance of Foo.
It's not even true that *once initialised* the property will always contain
a Foo, because (if I understand it correctly) it is also allowed to call
unset() on a non-nullable property at any time.
> That is, the former
> provides *better* support for non-nullable types.
>
The property is only "non-nullable" because we have invented a new state,
very similar to null, and called it something other than "null".
> To prevent all forms of initialization errors we would have to do
> analysis at the initialization site and prevent dynamic behaviors in
> that region. For now I believe such things are better left to static
> analysis tools than the engine.
>
I agree that this is a hard problem, but I don't agree that this decision
is being made "for now". If we allow "non-nullable but uninitialized"
properties now, it will be extremely hard to change their behaviour in
future.
My request is emphatically not to reject the entire RFC until this is
solved. It is to say that "for now", all typed properties must be
initialised inline to a valid value; and by implication, that a
non-nullable object hint cannot be used.
Regards,
--
Rowan Collins
[IMSoP]
