Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115231
MIME-Version: 1.0
References: <CAHRtwKZBy5SWBoGHNNwnd89jgh1oBaN5GtrRzQveh7=dKsUMfA@mail.gmail.com>
 <CAF+90c_cVGM9ETJh2++38Pz=9LFPBRgeXZvLRhwKef61TjkuTg@mail.gmail.com>
In-Reply-To: <CAF+90c_cVGM9ETJh2++38Pz=9LFPBRgeXZvLRhwKef61TjkuTg@mail.gmail.com>
Date: Wed, 30 Jun 2021 11:55:44 +0200
Message-ID: <CAHRtwKb+1+qwubezkNTDm7JKCVpZ_pt2CXLa4iqvJvOdwM_doA@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Larry Garfield <larry@garfieldtech.com>, PHP Internals List <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Re: [RFC] Readonly properties
From: andre.romcke@gmail.com (=?UTF-8?B?QW5kcsOpIFLDuG1ja2U=?=)

> Yes, this is a possible alternative interpretation of the readonly concep=
t. The current proposal is closer to how Java final variables work, which n=
ever allow reassignment, while your suggestion is closer to C# readonly, wh=
ich does allow reassigning in the constructor.
>
> I went with the current proposal, because it integrates nicely with the i=
nitialization concept introduced by typed properties. At the time, we also =
had lots of discussions about how typed property initialization should work=
, and requiring that all typed properties be initialized by the end of the =
constructor was one of the contenders. However, we ultimately decided again=
st such an approach, because it does not integrate well with other aspects =
of the language. In particular we need to have the ability to initialize an=
 object while bypassing the constructor, and we don't have the ability to d=
etermine initialization statically, so an uninitialized state would have be=
en required in any case.
>
> If we had gone with that alternative initialization model at the time, th=
en we would also use the same one for readonly properties. But that's not h=
ow things work now. Doing something like this now would require introducing=
 an entirely new scoping concept. This brings up awkward questions like: Ho=
w do you bind a closure to this new "initialization scope"? Closure rebindi=
ng is a common way to bypass visibility restrictions. What happens if you w=
ant to call a helper method to do the initialization, does that still count=
 as initialization scope? What if you call $object->__construct() directly,=
 will that allow changing properties?
>
> The current proposal tries to provide a simple, absolute guarantee: Once =
initialized, the property will never change again. I think that makes the f=
eature easy to understand and reason about.


Thanks for the detailed explanation, I'm sold!
And it seems it can evolve further once complementary features are introduc=
ed.