Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103181
MIME-Version: 1.0
References: <AM0PR0702MB3684F2B7EFF1826F515BA940E2040@AM0PR0702MB3684.eurprd07.prod.outlook.com>
 <CALKiJKqgM=YsyqodP-4QNL52q8L05ZZxUD8iyGk9L+O9c9m1+w@mail.gmail.com>
In-Reply-To: <CALKiJKqgM=YsyqodP-4QNL52q8L05ZZxUD8iyGk9L+O9c9m1+w@mail.gmail.com>
Date: Wed, 19 Sep 2018 09:56:48 -0600
Message-ID: <CAFMT4NoxeswyFYp4xMegrA5wLGTtxettWgMpL2a4L_-F_7cXgg@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2
From: levim@php.net (Levi Morrison)

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.