On Wed, Sep 19, 2018 at 6:38 AM Rowan Collins <rowan.coll...@gmail.com> wrote:
>
> On Tue, 11 Sep 2018 at 08:05, Bob Weinand <bobw...@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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
