Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127359
Precedence: bulk
MIME-Version: 1.0
References: <CAMzRQTdePFXUMWO38g=gQA2vbqL5zp=o1cPt00ec41g95xys=g@mail.gmail.com>
 <533ea02a-dd69-4de9-8526-f808c5a9f4a1@app.fastmail.com>
In-Reply-To: <533ea02a-dd69-4de9-8526-f808c5a9f4a1@app.fastmail.com>
Date: Wed, 14 May 2025 21:54:47 +0200
Message-ID: <CAMzRQTc=H24YuFf1Sk2icmfNJp03zyz-+qp8Y88=NFPzNDrjkQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Clone with v2
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000956d2006351dec73"
From: volker@tideways-gmbh.com (Volker Dusch)

--000000000000956d2006351dec73
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, May 14, 2025 at 5:40=E2=80=AFPM Larry Garfield <larry@garfieldtech.=
com>
wrote:
>> A magic __clone() method will be called before the new properties are
assigned.
> Why before and not after?  I could probably make a good argument either
direction, but we should be explicit about why we're making whatever
decision.

From a user-facing perspective, calling __clone() before makes it easy to
know which state the object is in; all parameters are how they've been
before the clone operation started and are therefore consistent. When
calling __clone() afterward access to the new properties would already be
set and the old ones gone, making this potentially harder to work with and
harder to adapt existing implementations. So we chose the one that causes
fewer potential issues and gotchas.

> The last example, on readonly, is a bit confusing.  It looks like it
should work, but the comments say "but if we did this other thing we'd get
this error."  Just make it two separate classes and show one works and one
doesn't.  That makes it easier to follow.
I've added the output to the var_dump statements to show what works.
Standalone examples for the "missing" (set) felt more confusing than
showing the difference in context and because its behavior is unaffected by
the RFC and mostly documented in case someone isn't familiar with this
detail in PHP, which I assume readers here will be.

>> Alternatively, we could drop the variadic syntax and instead only accept
an array as the second parameter. We're looking for feedback here in the
discussion.
> Oh lord please no. :-)  Not using an array here is what I like about this
syntax.  An __object parameter is fine with me as a workaround.  One
shouldn't be using a named argument for that anyway.

Thank you for your feedback! I'm looking forward to hearing what other
people say as well, but it's nice to get a range of voices giving input
here :)

Let me just reiterate here that I find the difference to be minor to
negligible. IDE/Tooling support needs to be built explicitly either way and
is not harder or easier to do, and the ergonomics are quite unaffected in
my opinion. So the worst outcome, for me, would be that we get hung up on
the syntax here.

>  One shouldn't be using a named argument for that anyway.

I'm not sure what you mean by that. Just so we're clear: `...["__object" =
=3D>
"foo"]` would also not work with the current implementation, as that's the
same thing as a `__object: $value` named argument. (Should we decide to
name the first parameter __object here). Sorry if I'm misunderstanding.

Kind Regards,
Volker

--=20
Volker Dusch
Head of Engineering
Tideways GmbH
K=C3=B6nigswinterer Str. 116
53227 Bonn
https://tideways.io/imprint

Sitz der Gesellschaft: Bonn
Gesch=C3=A4ftsf=C3=BChrer: Benjamin Au=C3=9Fenhofer (geb. Eberlei)
Registergericht: Amtsgericht Bonn, HRB 22127

--000000000000956d2006351dec73
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><br></d=
iv><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed,=
 May 14, 2025 at 5:40=E2=80=AFPM Larry Garfield &lt;<a href=3D"mailto:larry=
@garfieldtech.com" target=3D"_blank">larry@garfieldtech.com</a>&gt; wrote:<=
/div><div dir=3D"ltr" class=3D"gmail_attr">&gt;&gt; A magic __clone() metho=
d will be called before the new properties are assigned.</div><div dir=3D"l=
tr" class=3D"gmail_attr">&gt; Why before and not after?=C2=A0 I could proba=
bly make a good argument either direction, but we should be explicit about =
why we&#39;re making whatever decision.</div><div dir=3D"ltr" class=3D"gmai=
l_attr"><br></div><div class=3D"gmail_attr">From a user-facing perspective,=
 calling __clone() before makes it easy to know which state the object is i=
n; all parameters are how they&#39;ve been before the clone operation start=
ed and are therefore consistent. When calling __clone() afterward access to=
 the new properties would already be set and the old ones gone, making this=
 potentially harder to work with and harder to adapt existing implementatio=
ns. So we chose the one that causes fewer potential issues and gotchas.=C2=
=A0=C2=A0</div><div dir=3D"ltr" class=3D"gmail_attr"><br></div><div dir=3D"=
ltr" class=3D"gmail_attr">&gt; The last example, on readonly, is a bit conf=
using.=C2=A0 It looks like it should work, but the comments say &quot;but i=
f we did this other thing we&#39;d get this error.&quot;=C2=A0 Just make it=
 two separate classes and show one works and one doesn&#39;t.=C2=A0 That ma=
kes it easier to follow.</div><div class=3D"gmail_attr">I&#39;ve added the =
output to the var_dump statements to show what works. Standalone examples f=
or the &quot;missing&quot; (set) felt more confusing than showing the diffe=
rence in context and because its behavior is unaffected by the RFC and most=
ly documented in case someone isn&#39;t familiar with this detail in PHP, w=
hich I assume readers here will be.</div><div class=3D"gmail_attr"><br></di=
v><div class=3D"gmail_attr">&gt;&gt; Alternatively, we could drop the varia=
dic syntax and instead only accept an array as the second parameter. We&#39=
;re looking for feedback here in the discussion.</div><div class=3D"gmail_a=
ttr">&gt; Oh lord please no. :-)=C2=A0 Not using an array here is what I li=
ke about this syntax.=C2=A0 An __object parameter is fine with me as a work=
around.=C2=A0 One shouldn&#39;t be using a named argument for that anyway.<=
/div><div class=3D"gmail_attr"><br></div><div class=3D"gmail_attr">Thank yo=
u for your feedback! I&#39;m looking forward to hearing what other people s=
ay as well, but it&#39;s nice to get a range of voices giving input here :)=
=C2=A0</div><div class=3D"gmail_attr"><br></div><div class=3D"gmail_attr">L=
et me just reiterate here that I find the difference to be minor to negligi=
ble. IDE/Tooling support needs to be built explicitly either way and is not=
 harder or easier to do, and the ergonomics are quite unaffected in my opin=
ion. So the worst outcome, for me, would be that we get hung up on the synt=
ax here.</div></div><div><br></div><div>&gt;=C2=A0 One shouldn&#39;t be usi=
ng a named argument for that anyway.</div><div><br></div><div>I&#39;m not s=
ure what you mean by that. Just so we&#39;re clear: `...[&quot;__object&quo=
t; =3D&gt; &quot;foo&quot;]` would also not work with the current implement=
ation, as that&#39;s the same thing as a `__object: $value` named argument.=
 (Should we decide to name the first parameter __object here). Sorry if I&#=
39;m misunderstanding.</div><div><br></div><div>Kind Regards,</div><div>Vol=
ker</div><div><br></div><span class=3D"gmail_signature_prefix">-- </span><b=
r><div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"ltr"><div style=3D=
"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px">Volker =
Dusch</div><div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;f=
ont-size:12.8px">Head of Engineering</div><div style=3D"color:rgb(34,34,34)=
;font-family:arial,sans-serif;font-size:12.8px"><div>Tideways GmbH</div><di=
v>K=C3=B6nigswinterer Str. 116</div><div>53227 Bonn</div><div><a href=3D"ht=
tps://tideways.io/imprint" style=3D"color:rgb(17,85,204)" target=3D"_blank"=
>https://tideways.io/imprint</a><br></div><div><br></div><div>Sitz der Gese=
llschaft: Bonn</div><div>Gesch=C3=A4ftsf=C3=BChrer: Benjamin Au=C3=9Fenhofe=
r (geb. Eberlei)</div><div>Registergericht: Amtsgericht Bonn, HRB 22127</di=
v></div></div></div></div>
</div>
</div>

--000000000000956d2006351dec73--