Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103212
MIME-Version: 1.0
References: <AM0PR0702MB3684F2B7EFF1826F515BA940E2040@AM0PR0702MB3684.eurprd07.prod.outlook.com>
 <CALKiJKqgM=YsyqodP-4QNL52q8L05ZZxUD8iyGk9L+O9c9m1+w@mail.gmail.com>
 <CAFMT4NoxeswyFYp4xMegrA5wLGTtxettWgMpL2a4L_-F_7cXgg@mail.gmail.com>
 <CALKiJKrL8cXAJaNTNk5o7Je7X4g1TcKc8fYj1R86Skcu0rNXsA@mail.gmail.com>
 <CADqTB_i4=J8wb3tMz880PfSOh1-BdM_NBYRbxN0bOkhY3bsLmg@mail.gmail.com>
 <CAFMT4NoZ2L9uvCf2sg6Hbf_aF4g_nkvSUA2A9+eG9NpgRZjyhQ@mail.gmail.com>
 <CADqTB_g8-ARgCChoeze82T8xQHCzjWPzUHsxFV807DyVz4LPPQ@mail.gmail.com> <CAFMT4NpD6b8ihe-fa=wyn2c74iNBQWCApnZxyZWH6u32TL0O2w@mail.gmail.com>
In-Reply-To: <CAFMT4NpD6b8ihe-fa=wyn2c74iNBQWCApnZxyZWH6u32TL0O2w@mail.gmail.com>
Date: Fri, 21 Sep 2018 09:58:21 +0200
Message-ID: <CADqTB_gGj0uP5C_UvkEeC061tFQkAKug1OFbeoCkq=TK_aMo1g@mail.gmail.com>
To: levim <levim@php.net>
Cc: rowan.collins@gmail.com, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2
From: rasmus@mindplay.dk (Rasmus Schultz)

On Thu, Sep 20, 2018 at 4:50 PM Levi Morrison <levim@php.net> wrote:
>
> This will be my last reply to this thread. Fundamentally:
>
> class User {
>      public ?int $id;
>      public ?string $preferred_name;
>      public ?string $username;
>  }
>
> ^ This permits null properties at all times. This is acceptable
> behavior if null is valid for the domain. It is not valid for this
> domain -- all 3 are required.

If all three are required, your constructor needs to reflect that.

The reason constructors even exist in the first place is to initialize
the object's data members and establishing the invariant of the class.

Constructors are supposed to prepare objects for use.

Your (empty, implicit) constructor isn't doing that.

Your reasoning about this is circular - you want your properties to
be optionally initialized and non-null at the same time. You get
around this by coming up with a new term "undefined" for a
special kind of null that triggers run-time exceptions on read.

The whole idea is unnecessarily complex, and will certainly lead
to silent bugs that allow partially-initialized domain objects to
pass through many layers of a system without getting caught
until some code tries to read an "uninitialized" property.

function make_foo(): Foo {
   return new Foo(); // missing a property
}

function x() { ... }
function y() { ... }
function z() { ... }

x(y(z(make_foo()));

The instance travels through layers and layers of callls and
fails somewhere in the x() or y() function because of a missing
value ... why was the value missing? why wasn't it initialized?
where was it supposed to have been initialized? where did
this bad instance of Foo even come from?

All that information is lost in a call-stack that's long gone by
the time you invoke x() and you'll have to backtrack through
layers and layers of code to try to figure out where this bad
instance came from.

This will be an everyday thing with code like that.

To say that we don't need to enforce invariants at the time of
construction is to say we don't need to enforce them at all -
enforcing them "maybe later" is the same as not enforcing
them. That is, when they trigger an error, it's no different
from a null-value triggering a similar error.

No matter how you twist it, uninitialized is the new null.

I'm fine with unintialized as an implementation detail that
ensures you can't read from properties while the constructor
is busy establishing the invariant.

I'm not at all fine with unintialized as a new language feature.