Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120546
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-447-ge2460e13b3-fm-20230525.001-ge2460e13
Mime-Version: 1.0
Message-ID: <e13aa53c-1c7c-47dd-8179-ca64ec180344@app.fastmail.com>
In-Reply-To: 
 <CAOWwgpncC043ciO7HTuX954bfb+KWZ903zxKhQT-VigZh0WyYg@mail.gmail.com>
References: 
 <CAH5C8xUn2wotLg0L7KZHoOGf3q-UqbL=47p2PLzK_mOBb=MJXQ@mail.gmail.com>
 <CAOWwgpncdhKvhwiAFUh_c_8+_vr=u9HhYxws_WZArh7W3Fi0xw@mail.gmail.com>
 <799ae864-6e25-4196-a5ce-0d74600a8378@app.fastmail.com>
 <CAAwdEzCbRdDHN=WYZy_jnyrM9USG9k9bxn=AW-KVWB8iSrBmrQ@mail.gmail.com>
 <CAOWwgp=Ch2iwOzxooiRcfk3WYMz-eYmQ51M-UP2Hh3bDogX5uw@mail.gmail.com>
 <CAH5C8xV76ou5Edpvq-vzb6RytW5-3uGanX+Sqf92-qnH26ccBw@mail.gmail.com>
 <CABdc3WqsVq4Jo1tt5EOevQ15aXhLA1+6SRmSENc8-K7SHX20Hg@mail.gmail.com>
 <280bcea8-9483-4191-80d3-81763a988290@app.fastmail.com>
 <CAH5C8xVhiByYaRqF8nKqj=m=xanPt=WDOPOy0Rt3G48pNutJ6Q@mail.gmail.com>
 <5db38bc4-a6fd-4cb7-b10d-3ad1a590888c@app.fastmail.com>
 <CAAwdEzCNYcCJC=qzCNwoCo_GsVM=ZiBvo3kSd5_LM=7U=+7u3g@mail.gmail.com>
 <39511e44-93cb-4fde-b0ec-ce24ee88f4be@app.fastmail.com>
 <CAAwdEzCbUbwX1+ZyhAC0R_R0uYt5zNirz6vNO07=Ao+zr9eN+A@mail.gmail.com>
 <CAOWwgpncC043ciO7HTuX954bfb+KWZ903zxKhQT-VigZh0WyYg@mail.gmail.com>
Date: Thu, 08 Jun 2023 19:26:36 +0000
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] [Discussion] Clone with
From: larry@garfieldtech.com ("Larry Garfield")

On Thu, Jun 8, 2023, at 6:15 PM, Nicolas Grekas wrote:
>> On Tue, May 30, 2023, at 10:04 PM, Alexandru P=C4=83tr=C4=83nescu wro=
te:
>> > > On Tue, May 30, 2023, 19:39 Larry Garfield <larry@garfieldtech.co=
m>
>> > wrote:
>> > >
>> > >> On Mon, May 29, 2023, at 11:22 PM, M=C3=A1t=C3=A9 Kocsis wrote:
>> > >> > To be honest, the current behavior seemed like the natural cho=
ice
>> for
>> > >> > me, and I didn't really consider to execute the __clone() meth=
od
>> after
>> > >> the
>> > >> > clone assignments.
>> > >> > Do you have a use-case in mind when you need to forward-pass
>> > information
>> > >> to
>> > >> > __clone()?
>> > >>
>> > >> Not a specific one off hand.  It's more a conceptual question.  =
`with`
>> > has
>> > >> more contextual awareness than __clone(), so it should have "fir=
st
>> > crack"
>> > >> at the operation, so that if necessary it can make changes that
>> > __clone()
>> > >> can then respond to.  The inverse doesn't make sense.
>> > >>
>> > >> The only reason for `with` to come after would be to allow `with=
` to
>> > >> "override" or "undo" something that __clone() did.  Generally
>> speaking,
>> > if
>> > >> you have to undo something you just did, you shouldn't have done=
 it in
>> > the
>> > >> first place, so that's a less compelling combination.
>> > >>
>> > >> This one isn't a deal breaker, but we should be sure to think it
>> through
>> > >> as it's kinda hard to reverse later.
>> > >>
>> > >
>> > > To me so far also it was natural to assume that __clone is first =
and
>> only
>> > > after that the rest of the operations.
>> > > But `with` operations, be it properties assignment or even a clos=
ure,
>> > would
>> > > run in the context of the caller of clone and sometimes this migh=
t be
>> run
>> > > not from a method of the cloned class.
>> > >
>> > > An example:
>> > > There is a class that represents persons of a fictive country/pla=
net.
>> > > Each person has many properties but has also a first name and a l=
ast
>> name
>> > > and there is a rule: the two names must not start with the same l=
etter.
>> > > Both names cannot be changed as they are defined readonly.
>> > > Creation of new persons can be done using new for new random prop=
erties
>> > or
>> > > using clone to preserve existing properties. But in both cases the
>> first
>> > > name and last name are randomly chosen.
>> > > If we want to control the last name value during clone that would=
 be
>> > > possible using the `with` operation but the logic to allocate a f=
irst
>> > name
>> > > will only happen in `__clone()`method.
>> > >
>> > > To be able to achieve this we must have __clone last, as there we=
 have
>> > the
>> > > internal validations, operations and also access to private/prote=
cted
>> > > members that are not accesible from where clone is being called.
>> > >
>> > > Regards,
>> > > Alex
>> >
>> > I... could not understand that in the slightest.  Can you show it in
>> code?
>> >
>> >
>>
>> Sorry for that. Here you go: https://3v4l.org/JIBoI/rfc#vgit.master
>> If __clone would be first, there is no way to enforce the rule that a
>> person cannot have their first name starting with the same letter as =
last
>> name.
>>
>
> I'm not sure that's what __clone should be used for.
> This looks like a perfect use case for property hooks, isn't it?
>
> On my side, I would find it unexpected that __clone is called after be=
cause
> that would break cloning expectations:
> Imagine you have a __clone that does some deep cloning (a much more ty=
pical
> scenario for this construct),
> Let's say __clone() does $this->foo =3D clone $this->foo;
>
> Imagine now that you do: clone $obj with (foo: $bar)
> I'd expect $obj->foo =3D=3D=3D $bar after this. But if __clone is call=
ed after,
> that won't be true, and I don't see how that could be "fixed" if we sw=
ap
> the order. Would you?
>
> Nicolas

Oh, interesting.  There's a nice example case.  To make it a bit more co=
ncrete, and think aloud...=20

class Pet {
  public function __construct(
    public readonly string $name =3D 'Fluffy',
  ) {}
}

class Address { ... }

class Person {
  public function __construct(
    public readonly Pet $pet,
    public readonly Address $address,
  }

  public function __clone() {
    // Legal now thanks to a previous RFC.
    $this->address =3D clone ($this->address);
  }
}

$p =3D new Person(new Pet(), new Address(blah));

// The person gets a new pet.
$p2 =3D clone $p with (pet: new Pet('Bonzo'));

In this case, the order of operations is irrelevant.

// The person moves.
$newAddr =3D new Address(whatever);
$p3 =3D clone $p2 with (address: $newAddr);

In this case, if the `with` happens first, then the new address object i=
s cloned needlessly, but that *probably* doesn't hurt anything.  But $ne=
wAddr !=3D=3D $p3->address.

If the `__clone()` happens first, then the existing address object is cl=
oned needlessly, but that *probably* doesn't hurt anything.  Because the=
 assignment happens second, $newAddr =3D=3D=3D $p3->address.

So I suppose that's a point in favor of __clone() first.

Another option could be to run `with` first, but then pass a list of the=
 keys that were modified (probably not their values, just the keys?) to =
__clone().  It can then do conditional cloning based on that if appropri=
ate.  I... don't know if that's a good idea or not, nor what the BC impl=
ications might be.

M=C3=A1t=C3=A9, your thoughts?

--Larry Garfield