Re: [RFC] [VOTE] Typed properties v2

On Wed, Sep 19, 2018 at 6:38 AM Rowan Collins <rowan.collins@gmail.com> wrote: > > On Tue, 11 Sep 2018 at 08:05, Bob Weinand <bobwei9@hotmail.com> wrote: > > > Hey, > > > > As announced, we are starting the vote on typed properties today. > > > > The voting period is two weeks, until sometime in the evening on Tuesday > > 25-09-2018. > > > > Please find the RFC at > > https://wiki.php.net/rfc/typed_properties_v2. > > > > > For the record, I still think we will come to regret allowing non-nullable > type hints without any constraint on the author of the class to initialise > them correctly. As proposed, the invalid state may only be detected when it > causes a runtime error in completely unrelated code. > > I gather that the authors of C# are currently going through a painful > development phase to introduce better support for non-nullable types, and > having to include many compromises and handle many edge-cases because it > was not done earlier. I realise this case is not completely comparable, but > we have an opportunity to get this right first time, and not just take the > easy option. > > I am therefore going to make one last plea: if we don't yet know how to > assert that complex types are initialised, do not allow them to be > non-nullable in the first version of this feature. > > That is, allow class Foo { public ?Foo $foo = null; }, but not > `class Foo > { public Foo $foo; }`. > > This would still be a huge improvement to the language, but leaves us free > to design additional features to prevent Unitialized Property Errors > becoming as hated as Null Pointer Exceptions in Java or C#. > > Regards, > -- > Rowan Collins > [IMSoP] 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. 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. That is, the former provides *better* support for non-nullable types. 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.