Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129989
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Tue, 03 Feb 2026 10:00:03 +0100
To: "Nicolas Grekas" <nicolas.grekas+php@gmail.com>
Cc: "PHP Internals List" <internals@lists.php.net>
Message-ID: <585bfc82-a522-43ec-be42-b8945952fe8b@app.fastmail.com>
In-Reply-To: 
 <CAOWwgpnrnk-a6uczGnuE76rpd9mZvwXs=SHwuo+-4fWgLm9Jcg@mail.gmail.com>
References: 
 <CAOWwgp=JtbTSVCv9z=QGx9yS=8G72L-hcAjcOj33eEMLB0zfvg@mail.gmail.com>
 <CADyq6sJMXmDixLPO91P5d+5V28zhu0TVVfLxBKSUfF41JtYjkw@mail.gmail.com>
 <CAOWwgpnToAqGN=_bj9JB8gj-2PO9gqq2SgFYYg6LmPTSmCyQ=Q@mail.gmail.com>
 <4b74f9a1-96d2-4104-abdd-fe56c5e7016c@app.fastmail.com>
 <CAOWwgpnrnk-a6uczGnuE76rpd9mZvwXs=SHwuo+-4fWgLm9Jcg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Allow Reassignment of Promoted Readonly Properties in
 Constructor
Content-Type: multipart/alternative;
 boundary=ed867ea2001f407cab0d25d0136cea69
From: rob@bottled.codes ("Rob Landers")

--ed867ea2001f407cab0d25d0136cea69
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tue, Feb 3, 2026, at 09:56, Nicolas Grekas wrote:
> Hi Rob,
>=20
> Le mar. 3 f=C3=A9vr. 2026 =C3=A0 09:50, Rob Landers <rob@bottled.codes=
> a =C3=A9crit :
>> __
>> On Mon, Feb 2, 2026, at 22:14, Nicolas Grekas wrote:
>>> Hi Marco,
>>>=20
>>> Le lun. 2 f=C3=A9vr. 2026 =C3=A0 11:54, Marco Pivetta <ocramius@gmai=
l.com> a =C3=A9crit :
>>>> Hey Nicolas,
>>>>=20
>>>>=20
>>>> On Thu, 22 Jan 2026 at 16:34, Nicolas Grekas <nicolas.grekas+php@gm=
ail.com <mailto:nicolas.grekas%2Bphp@gmail.com>> wrote:
>>>>> Dear all,
>>>>>=20
>>>>> Here is a new RFC for you to consider:
>>>>> https://wiki.php.net/rfc/promoted_readonly_constructor_reassign
>>>>=20
>>>>=20
>>>> What happens if one calls `$obj->__construct(1, 2, 3)` (on an alrea=
dy instantiated `$obj`) in the context of this patch?
>>>=20
>>> Thanks for asking, I didn't think about this. This made me also thin=
k about ReflectionClass::newInstanceWithoutConstructor().
>>> I clarified this in the RFC, see "Direct __construct() Calls Cannot =
Bypass Readonly" and "Reflection: Objects Created Without Constructor".
>>> Patch and PR updated also if anyone wants to run some code where thi=
s RFC can be played with.
>>>=20
>>> Cheers,
>>> Nicolas
>>=20
>> Hi Nicolas,
>>=20
>> Under "Child Classes Can Reassign Parent Properties": this feels like=
 a major footgun. Calling parent::__construct() won't allow a reset (per=
 the rules of calling a constructor directly); which would completely br=
eak inheritance... but then in the examples it says that calling a const=
ructor directly can reset it -- but you can't?
>>=20
>> This feels really inconsistent to me.
>>=20
>> =E2=80=94 Rob
>=20
> Yes, the text was ambiguous. The implementation allows parent::__const=
ruct() during the initial construction (normal inheritance), and only bl=
ocks explicit __construct() calls after construction completed. I=E2=80=99=
ve clarified this in the RFC.
>=20
> Nicolas

Will this result in a catchable error? I assume so, so a valid pattern d=
uring inheritance might be to put these in a try/catch so children can s=
et them first?

FWIW, in my Records RFC, properties were fully mutable during constructi=
on for exactly this reason.=20

=E2=80=94 Rob
--ed867ea2001f407cab0d25d0136cea69
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div>On Tue, Feb =
3, 2026, at 09:56, Nicolas Grekas wrote:</div><blockquote type=3D"cite" =
id=3D"qt" style=3D""><div dir=3D"ltr"><div dir=3D"ltr">Hi Rob,</div><div=
><br></div><div class=3D"qt-gmail_quote qt-gmail_quote_container"><div d=
ir=3D"ltr" class=3D"qt-gmail_attr">Le&nbsp;mar. 3 f=C3=A9vr. 2026 =C3=A0=
&nbsp;09:50, Rob Landers &lt;rob@bottled.codes&gt; a =C3=A9crit&nbsp;:</=
div><blockquote class=3D"qt-gmail_quote" style=3D"margin-top:0px;margin-=
right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;bord=
er-left-style:solid;border-left-color:rgb(204, 204, 204);padding-left:1e=
x;"><div><u></u><br></div><div><div>On Mon, Feb 2, 2026, at 22:14, Nicol=
as Grekas wrote:</div><blockquote type=3D"cite" id=3D"qt-m_6564486400604=
031585qt"><div dir=3D"ltr"><div dir=3D"ltr">Hi Marco,</div><div><br></di=
v><div><div dir=3D"ltr">Le&nbsp;lun. 2 f=C3=A9vr. 2026 =C3=A0&nbsp;11:54=
, Marco Pivetta &lt;<a href=3D"mailto:ocramius@gmail.com" target=3D"_bla=
nk">ocramius@gmail.com</a>&gt; a =C3=A9crit&nbsp;:</div><blockquote styl=
e=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex=
;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204=
, 204, 204);padding-left:1ex;"><div dir=3D"ltr"><div dir=3D"ltr"><div>He=
y Nicolas,</div><div><br></div></div><div><br></div><div><div dir=3D"ltr=
">On Thu, 22 Jan 2026 at 16:34, Nicolas Grekas &lt;<a href=3D"mailto:nic=
olas.grekas%2Bphp@gmail.com" target=3D"_blank">nicolas.grekas+php@gmail.=
com</a>&gt; wrote:</div><blockquote style=3D"margin-top:0px;margin-right=
:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-le=
ft-style:solid;border-left-color:rgb(204, 204, 204);padding-left:1ex;"><=
div dir=3D"ltr"><div>Dear all,</div><div><br></div><div>Here is a&nbsp;n=
ew RFC for you to consider:</div><div><a href=3D"https://wiki.php.net/rf=
c/promoted_readonly_constructor_reassign" target=3D"_blank">https://wiki=
.php.net/rfc/promoted_readonly_constructor_reassign</a></div></div></blo=
ckquote><div><br></div><div><div><br></div><div>What happens if one call=
s `$obj-&gt;__construct(1, 2, 3)` (on an already instantiated `$obj`) in=
 the context of this patch?</div></div></div></div></blockquote><div><br=
></div><div>Thanks for asking, I didn't think about this. This made me a=
lso think about ReflectionClass::newInstanceWithoutConstructor().</div><=
div>I clarified this in the RFC, see "Direct __construct() Calls Cannot =
Bypass Readonly" and "Reflection: Objects Created Without Constructor".<=
/div><div>Patch and PR updated also if anyone wants to run some code whe=
re this RFC can be played with.</div><div><br></div><div>Cheers,</div><d=
iv>Nicolas</div></div></div></blockquote><div><br></div><div>Hi Nicolas,=
</div><div><br></div><div>Under "Child Classes Can Reassign Parent Prope=
rties": this feels like a major footgun. Calling parent::__construct() w=
on't allow a reset (per the rules of calling a constructor directly); wh=
ich would completely break inheritance... but then in the examples it sa=
ys that calling a constructor directly can reset it -- but you can't?</d=
iv><div><br></div><div>This feels really inconsistent to me.</div><div><=
br></div><div id=3D"qt-m_6564486400604031585sig121229152">=E2=80=94 Rob<=
/div></div></blockquote><div><br></div><div>Yes, the text was ambiguous.=
 The implementation allows parent::__construct() during the initial cons=
truction (normal inheritance), and only blocks explicit __construct() ca=
lls after construction completed. I=E2=80=99ve clarified this in the RFC=
.</div><div><br></div><div>Nicolas</div></div></div></blockquote><div><b=
r></div><div>Will this result in a catchable error? I assume so, so a va=
lid pattern during inheritance might be to put these in a try/catch so c=
hildren can set them first?</div><div><br></div><div>FWIW, in my Records=
 RFC, properties were fully mutable during construction for exactly this=
 reason.&nbsp;</div><div><br></div><div id=3D"sig121229152">=E2=80=94 Ro=
b</div></body></html>
--ed867ea2001f407cab0d25d0136cea69--