Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127374
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Mime-Version: 1.0 (1.0)
Subject: Re: [PHP-DEV] [RFC] Clone with v2
Date: Thu, 15 May 2025 18:56:15 +0700
Message-ID: <266FA35A-15B0-435E-BBFE-1C6926EB0B7E@koalephant.com>
References: <CAB-BujZLV=dccE6WjBFaLMSM977=fmJOirHSTbhJ1GuZj6iPdQ@mail.gmail.com>
Cc: Volker Dusch <volker@tideways-gmbh.com>,
 Matthew Weier O'Phinney <mweierophinney@gmail.com>,
 php internals <internals@lists.php.net>,
 =?utf-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
In-Reply-To: <CAB-BujZLV=dccE6WjBFaLMSM977=fmJOirHSTbhJ1GuZj6iPdQ@mail.gmail.com>
To: Andreas Hennings <andreas@dqxtech.net>
From: php-lists@koalephant.com (Stephen Reay)




> On 15 May 2025, at 16:44, Andreas Hennings <andreas@dqxtech.net> wrote:
>=20
> =EF=BB=BFOn Thu, 15 May 2025 at 08:24, Stephen Reay <php-lists@koalephant.=
com> wrote:
> [..]
>>=20
>>=20
>> I may be missing something here..
>>=20
>> So far the issues are "how do we deal with a parameter for the actual obj=
ect, vs new properties to apply",  "should __clone be called before or after=
 the changes" and "this won't allow regular readonly properties to be modifi=
ed".
>>=20
>> Isn't the previous suggestion of passing the new property arguments direc=
tly to the __clone method the obvious solution to all three problems?
>=20
> What exactly should happen then?
> Would the __clone() method be responsible for assigning those properties?
> Or does the __clone() method get the chance to alter the values before
> they are assigned?
> (this would mean they have to be passed by reference)
> I think this last option is the best, because the values in the array
> can be changed without any readonly constraints.
>=20
> Another option I was thinking of would be to call __clone() after the
> changes are applied, and pass both the original object and the array
> of changes as first parameter.
> But I think this is a dead end.
>=20
> -- Andreas
>=20
>>=20
>> There's no potential for a conflicting property name, the developer can u=
se the new property values in the order they see fit relative to the logic i=
n the __clone call, and it's inherently in scope to write to any (unlocked d=
uring __clone) readonly properties.
>>=20
>>=20
>>=20
>> Cheers
>>=20
>> Stephen
>>=20
>>=20
>>=20
>=20

I would suggest that the __clone method should be directly responsible for m=
aking any changes, just as it is now when it comes to deep cloning or resett=
ing values.

Yes I realise it means developers need to then opt in and provide the functi=
onality to support `clone $foo with(bar: "baz")` or whatever syntax is used.=
=20

If the properties are public properties, there's nothing stopping someone wr=
iting their own clone_with() in userland now;  If someone is using readonly p=
roperties I'd suggest they want to specifically manage updates to those prop=
erties themselves anyway.=20

Additionally it means "clone with" would be usable for non-public properties=
 at the discretion of the developer writing their code.=20

The mental model is also very clear with this: copy the object in memory, an=
d then call __clone(), with the arguments passed to the clone action - which=
 may be none in the case of code that doesn't accept any clone arguments.  T=
he only change from the current model is that it *may* be passing arguments.=
=20

Cheers

Stephen=20