Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102822
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.47 as permitted sender)
Date: Sat, 14 Jul 2018 14:09:01 +0100
User-Agent: K-9 Mail for Android
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----YYGPSB74JPBHQQS51NXS7F007AUYIG"
Content-Transfer-Encoding: 7bit
To: internals@lists.php.net
Message-ID: <8916EC21-D368-40F8-9ABD-CE0C04A73539@gmail.com>
Subject: Non-nullable properties
From: rowan.collins@gmail.com (Rowan Collins)

------YYGPSB74JPBHQQS51NXS7F007AUYIG
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi all,

As briefly mentioned, I think the approach to non-nullable types in the ty=
ped properties proposal needs more discussion, to make sure we're not repea=
ting Tony Hoare's "billion-dollar mistake"=2E

For parameter hints, nullability is naturally optional, particularly in PH=
P where "nullable Foo" is equivalent to a union type "null or Foo"=2E For p=
roperties, this isn't the case, because every property must have some initi=
al state=2E

The simplest solution, which I think would be a sensible starting point if=
 we're not ready for more complex changes, is to say that all typed propert=
ies must have a default value, and if that default value is null, the type =
hint must naturally be nullable=2E In other words, make "public Foo $foo" i=
llegal, but allow "public ?Foo $foo=3Dnull"=2E

The current RFC proposes the next simplest solution, which is to allow non=
-nullable types, and trust the user to initialise them before use=2E=20

My first objection to this is that it creates an entirely new state for ob=
ject properties to be in, which behaves differently from everything else in=
 the language=2E There will then be three or four different ways for an obj=
ect property to be "unset":

- not declared at all; access gives a notice and the implicit value null
- declared with no default, uninitialised, implicitly null
- declared with a default of null, or explicitly assigned as null
- declared with a non-nullable type, never initialised; rather than an imp=
licit null, access generates an Error

The bigger problem is that the properties are non-nullable in name only, a=
nd the declaration can't be trusted=2E Consider the following class:

class Validity {
    public \DateTimeInterface $validFrom;
    public ?\DateTimeInterface $validTo =3D null;
}

If I have an instance $v of that class, I would expect to be able to safel=
y call $v->validFrom->getTimestamp(), but need to check for nulls before do=
ing the same with validTo=2E Under the current proposal, doing so will risk=
 errors, so I will have to check both properties before access anyway=2E Wo=
rse, using is_null() or ?: will attempt to retrieve the value, so I actuall=
y have to be *more* careful, and use isset() or ?? instead=2E=20

Alternatively, I can trust the author of the class, but at that point they=
 might as well just use a docblock - the type hint documents their intent, =
but is not enforced=2E


Swift is often cited as a language which gets nullability right, and a lot=
 of attention is given to Options, and the compiler ensuring that the None =
/ null case is handled; but at least as important is how it handles initial=
isation of non-nullable properties, using "two-phase initialisation": https=
://docs=2Eswift=2Eorg/swift-book/LanguageGuide/Initialization=2Ehtml

In short, Swift defines a specific point after which all properties must h=
ave a valid value; before this point, the entire object is invalid for read=
 operations, so there is no need for a specific error when accessing uninit=
ialised properties=2E

Swift marks this point by the call to the parent initialiser, ultimately g=
oing up the chain to the root object=2E PHP has no root object, and no mand=
atory parent constructor calls, so would need a different way to mark this =
stage=2E Constructors can already violate the rules the first phase should =
impose, so we can't just use the end of the constructor as the validation p=
oint=2E

One possibility would be to add a new keyword like "initialize" which must=
 be added to constructors in the presence of non-nullable properties=2E Abo=
ve that keyword, use of $this other than to write to its properties would b=
e an error; afterwards, the constructor could carry on as normal=2E


As I say, this is complex, and it may be best to add nullable typed proper=
ties first, and give more time to try out approaches to initialisation=2E

Regards,
--=20
Rowan Collins
[IMSoP]
------YYGPSB74JPBHQQS51NXS7F007AUYIG--