Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127390
Precedence: bulk
MIME-Version: 1.0
References: <CAMzRQTdePFXUMWO38g=gQA2vbqL5zp=o1cPt00ec41g95xys=g@mail.gmail.com>
 <CAJp_myXREmnyufwxj4tDCsopouUFEWenap5EJaH+sXKTyg4K1Q@mail.gmail.com>
 <4a703db4174763586d84b9bf5606ff31@bastelstu.be> <b1bef725-5c17-47c4-8019-7f3135a5a682@app.fastmail.com>
 <956887e5b66e2b43459b999ebac2069d@bastelstu.be>
In-Reply-To: <956887e5b66e2b43459b999ebac2069d@bastelstu.be>
Date: Fri, 16 May 2025 21:39:51 +0200
Message-ID: <CAOWwgpkv-5BgLKM9xp9nmGRMu6u2yteQ4KO+6cOYKsF1ivtZ3w@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Clone with v2
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Cc: Larry Garfield <larry@garfieldtech.com>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000cffc9e063545f2e9"
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--000000000000cffc9e063545f2e9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Le jeu. 15 mai 2025 =C3=A0 15:55, Tim D=C3=BCsterhus <tim@bastelstu.be> a =
=C3=A9crit :

> Hi
>
> Am 2025-05-15 00:04, schrieb Larry Garfield:
> > Subtle point here.  If the __clone() method touches a readonly
> > property, does that make the property inaccessible to the new
> > clone-with?
>
> Yes. Quoting from the RFC:
>
> > The currently linked implementation =E2=80=9Clocks=E2=80=9D a property =
if it modified
> > within __clone(), if this is useful is up for debate.
>
> -
>
> > A single unlock block would be confusing to me.
>
> We=E2=80=99ve implemented it like that, because it felt most in line with=
 what
> was decided in
>
> https://wiki.php.net/rfc/readonly_amendments#proposal_2readonly_propertie=
s_can_be_reinitialized_during_cloning,
>
> which says:
>
> > Reinitialization of each property is possible once and only once:
>
> We expect =E2=80=9Cpublic(set) readonly=E2=80=9D + =E2=80=9C__clone()=E2=
=80=9D to be rare and from
> within the class, the author knows how their `__clone()` implementation
> works and can make sure it is compatible with whatever properties they
> might want to update during cloning. The lack of =E2=80=9Cuse cases=E2=80=
=9D is the
> primary reason we made the more conservative choice, but we are not
> particularly attached to this specific behavior.
>
>
Being able to update a readonly property even if __clone already touched it
looks critical to me because otherwise, it'd mean that adding a __clone
method after publishing a first version of some class that has no __clone
method would be a BC break.

Nicolas

--000000000000cffc9e063545f2e9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0jeu. 15=
 mai 2025 =C3=A0=C2=A015:55, Tim D=C3=BCsterhus &lt;<a href=3D"mailto:tim@b=
astelstu.be">tim@bastelstu.be</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex">Hi<br>
<br>
Am 2025-05-15 00:04, schrieb Larry Garfield:<br>
&gt; Subtle point here.=C2=A0 If the __clone() method touches a readonly <b=
r>
&gt; property, does that make the property inaccessible to the new <br>
&gt; clone-with?<br>
<br>
Yes. Quoting from the RFC:<br>
<br>
&gt; The currently linked implementation =E2=80=9Clocks=E2=80=9D a property=
 if it modified <br>
&gt; within __clone(), if this is useful is up for debate.<br>
<br>
-<br>
<br>
&gt; A single unlock block would be confusing to me.<br>
<br>
We=E2=80=99ve implemented it like that, because it felt most in line with w=
hat <br>
was decided in <br>
<a href=3D"https://wiki.php.net/rfc/readonly_amendments#proposal_2readonly_=
properties_can_be_reinitialized_during_cloning" rel=3D"noreferrer" target=
=3D"_blank">https://wiki.php.net/rfc/readonly_amendments#proposal_2readonly=
_properties_can_be_reinitialized_during_cloning</a>, <br>
which says:<br>
<br>
&gt; Reinitialization of each property is possible once and only once:<br>
<br>
We expect =E2=80=9Cpublic(set) readonly=E2=80=9D + =E2=80=9C__clone()=E2=80=
=9D to be rare and from <br>
within the class, the author knows how their `__clone()` implementation <br=
>
works and can make sure it is compatible with whatever properties they <br>
might want to update during cloning. The lack of =E2=80=9Cuse cases=E2=80=
=9D is the <br>
primary reason we made the more conservative choice, but we are not <br>
particularly attached to this specific behavior.<br>
<br></blockquote><div><br></div><div>Being able to update a readonly proper=
ty even if __clone already touched it looks critical to me because otherwis=
e, it&#39;d mean that adding a __clone method after publishing a first vers=
ion of some class that has no __clone method would be a BC break.</div><div=
><br></div><div>Nicolas</div><div><br></div></div></div>

--000000000000cffc9e063545f2e9--