Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127365
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Wed, 14 May 2025 17:08:47 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <c2b3ba5e-0315-4484-a768-a597dacab641@app.fastmail.com>
In-Reply-To: 
 <CAMzRQTc=H24YuFf1Sk2icmfNJp03zyz-+qp8Y88=NFPzNDrjkQ@mail.gmail.com>
References: 
 <CAMzRQTdePFXUMWO38g=gQA2vbqL5zp=o1cPt00ec41g95xys=g@mail.gmail.com>
 <533ea02a-dd69-4de9-8526-f808c5a9f4a1@app.fastmail.com>
 <CAMzRQTc=H24YuFf1Sk2icmfNJp03zyz-+qp8Y88=NFPzNDrjkQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Clone with v2
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Wed, May 14, 2025, at 2:54 PM, Volker Dusch wrote:
> On Wed, May 14, 2025 at 5:40=E2=80=AFPM Larry Garfield <larry@garfield=
tech.com> wrote:
>>> A magic __clone() method will be called before the new properties ar=
e assigned.
>> Why before and not after?  I could probably make a good argument eith=
er direction, but we should be explicit about why we're making whatever =
decision.
>
> From a user-facing perspective, calling __clone() before makes it easy=20
> to know which state the object is in; all parameters are how they've=20
> been before the clone operation started and are therefore consistent.=20
> When calling __clone() afterward access to the new properties would=20
> already be set and the old ones gone, making this potentially harder t=
o=20
> work with and harder to adapt existing implementations. So we chose th=
e=20
> one that causes fewer potential issues and gotchas. =20

Please include this in the RFC.

> Let me just reiterate here that I find the difference to be minor to=20
> negligible. IDE/Tooling support needs to be built explicitly either wa=
y=20
> and is not harder or easier to do, and the ergonomics are quite=20
> unaffected in my opinion. So the worst outcome, for me, would be that=20
> we get hung up on the syntax here.

I think the current syntax is optimal.

>>  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:=20
> `...["__object" =3D> "foo"]` would also not work with the current=20
> implementation, as that's the same thing as a `__object: $value` named=20
> argument. (Should we decide to name the first parameter __object here)=
.=20
> Sorry if I'm misunderstanding.

The concern is someone calling clone($foo, object: new Thingie()), which=
 would complain that "object" is defined twice.  Making the first argume=
nt named __object sidesteps that issue.

If someone then calls clone(prop: 'new val', __object: $foo), that... I =
suppose would technically compile, but one should never do that, and I a=
m perfectly happy if that breaks.  Similar for if someone called clone(p=
rop: 'new val', object: $foo) if we didn't rename that parameter.  No on=
e should be doing that and I am fine if that breaks.

--Larry Garfield