On 14 July 2018 19:29:23 BST, Levi Morrison <le...@php.net> wrote: >Whether it's a constructor, a factory method, or just a block of code >near the `new` site: something has the responsibility for >initialization.
Indeed, and my suggestion is to formalise that responsibility, so that mistakes can be detected closer to their source - which is, after all, the whole point of type constraints. > Once initialized the object provides guarantees unless >you `unset` the property. But since you have no way of knowing if it was initialized or not, this isn't a guarantee you can actually base code on. > It also provides the guarantee that if it is >set then it will always be of the outlined type; this is a much >stronger guarantee than we have today, which is... nothing. I'm not saying we should block the whole feature (apologies if that wasn't clear), so that's not the appropriate comparison. The comparison I'm interested in is between writing... /** * Will be initialised in the constructor and should not be unset. */ public Foo $foo; ... and ... /** * Will be initialised in the constructor and should not be set to null. */ public ?Foo $foo=null; In both cases, the intent is documented, but not enforced. If we allow the first version, with no actual checks on the initialisation, it will be very hard to introduce a stricter version later. If we only allow the second version in the initial implementation, we lose very little. The rule could be very simple: typed properties must specify a valid default value. That means object hints will have to be nullable, with a default of null, and there is no need to invent a new kind of "null reference". Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
