Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102825
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.208.170 as permitted sender)
MIME-Version: 1.0
References: <8916EC21-D368-40F8-9ABD-CE0C04A73539@gmail.com>
 <CAFMT4Np3we41HEYz3V4-JLGdxr9ToOMh9k=BpZR_idJTfSqcig@mail.gmail.com> <6E843F96-7815-4525-8AB1-D9D700B0D031@gmail.com>
In-Reply-To: <6E843F96-7815-4525-8AB1-D9D700B0D031@gmail.com>
Date: Sat, 14 Jul 2018 12:29:23 -0600
Message-ID: <CAFMT4NoZEivQtoueJ4B3aZvaJNGwjafcGucLo7xyp5qyNK-m5Q@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Non-nullable properties
From: levim@php.net (Levi Morrison)

On Sat, Jul 14, 2018 at 10:00 AM Rowan Collins <rowan.collins@gmail.com> wr=
ote:
>
> On 14 July 2018 15:37:32 BST, Levi Morrison <levim@php.net> wrote:
> >> class Validity {
> >>     public \DateTimeInterface $validFrom;
> >>     public ?\DateTimeInterface $validTo =3D null;
> >> }
> >
> >Even if this had a constructor we couldn't "trust" it because there
> >are ways to skip constructors.
>
> Then the mechanisms should either be impossible with non-nullable propert=
ies, or have a way to mark the object initialised. If not, the object creat=
ed would not be fully initialised, so accessing *the entire object* should =
be an error, not just accessing the specific properties which are marked no=
n-nullable.
>
> I'm not claiming any of this is easy, but if you can't guarantee a proper=
ty has a valid value, what is the type hint actually for?

Whether it's a constructor, a factory method, or just a block of code
near the `new` site: something has the responsibility for
initialization. Once initialized the object provides guarantees unless
you `unset` the property. 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.

It's worth discussing, and if someone has a brilliant idea maybe we
can proceed. However, in the absence of such an idea am I fine with
the outlined semantics of the RFC.