Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127415
Precedence: bulk
MIME-Version: 1.0
References: <CAMzRQTdePFXUMWO38g=gQA2vbqL5zp=o1cPt00ec41g95xys=g@mail.gmail.com>
 <CAMzRQTe_vn1a-ji9M2NXnBgJm3eHOGTHozWpM1jGzOht_sNs4w@mail.gmail.com> <2f30cae4add309021e18d0f359a1814e@bastelstu.be>
In-Reply-To: <2f30cae4add309021e18d0f359a1814e@bastelstu.be>
Date: Wed, 21 May 2025 16:27:07 +0200
Message-ID: <CAOWwgpnLgAhUP57aQDJT1KJ4ZanwKGPUqboDuP2oSgAN3CHbbA@mail.gmail.com>
Subject: Re: [PHP-DEV] Re: [RFC] Clone with v2
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Cc: Volker Dusch <volker@tideways-gmbh.com>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000a85cf50635a62978"
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--000000000000a85cf50635a62978
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Tim,

Le mer. 21 mai 2025 =C3=A0 16:15, Tim D=C3=BCsterhus <tim@bastelstu.be> a =
=C3=A9crit :

> Hi
>
> Am 2025-05-19 12:48, schrieb Volker Dusch:
> > We're still looking for feedback on the ...variadic approach to the
> > Syntax:
> > https://wiki.php.net/rfc/clone_with_v2#open_issues, as we only got one
> > reply so far on the topic.
>
> I was hoping for some additional opinions here before adding my own, but
> since this does not appear to happen, adding my personal opinion on this
> matter now:
>
> *Some* property name being completely incompatible with =E2=80=9Cclone wi=
th=E2=80=9D (no
> matter how the first parameter is going to be called) is a limitation
> that should not exist, it feels like a feature that is broken by design
> and I think I really would hate it if the documentation of this RFC
> would need a =E2=80=9CCaution: It is not possible to reassign a property =
called
> '$object', due to a parameter name conflict=E2=80=9D.
>
> Adjusting the signature to `clone(object $object, array
> $withProperties)` would not have this problem and I don't consider the
> additional verbosity of an array literal to be a problem. Static
> analysis tools already understand array shapes and would need
> adjustments either way to understand the semantics.
>
>  From an implementation PoV a regular array parameter would also be
> simpler, since the implementation would be able to simply pass along the
> input array, whereas the =E2=80=9Cvariadic=E2=80=9D syntax needs special =
handling to
> combine positional parameters with named parameters into a single array
> that is then used in the cloning process.
>
> Syntax-wise there might also be a middle-ground. Similarly to how this
> RFC turns `clone()` into a function, the `array()` syntax also looks
> like a function call and would naturally extend to named parameters.
> While mixing positional and named parameters would probably get complex,
> allowing purely named parameters would trivially be possible (without
> any function call overhead). It would also allow using the
> first-class-callable syntax with `array(...)`, something I would liked
> to have in the past. A proof of concept PR is at:
>
> https://github.com/php/php-src/pull/18613
>
> Combining named-parameter `array()` syntax with clone taking a array as
> the second parameter would allow for the following, which might combine
> the best of both worlds?
>
>      clone($obj, array(foo: 1, bar: "baz", object: "this is not
> blocked"));
>
>

Thanks for sharing your insights. This looks a bit far reaching for the RFC=
.

On my side, my opinion is: don't make clone a function call. I've never
missed not being able to call clone as a callback. It's trivial to write a
short function using the operator when in need.

Nicolas

--000000000000a85cf50635a62978
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi Tim,</div><br><div class=3D"gmail_quot=
e gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0mer.=
 21 mai 2025 =C3=A0=C2=A016:15, Tim D=C3=BCsterhus &lt;<a href=3D"mailto:ti=
m@bastelstu.be">tim@bastelstu.be</a>&gt; a =C3=A9crit=C2=A0:<br></div><bloc=
kquote 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-19 12:48, schrieb Volker Dusch:<br>
&gt; We&#39;re still looking for feedback on the ...variadic approach to th=
e <br>
&gt; Syntax:<br>
&gt; <a href=3D"https://wiki.php.net/rfc/clone_with_v2#open_issues" rel=3D"=
noreferrer" target=3D"_blank">https://wiki.php.net/rfc/clone_with_v2#open_i=
ssues</a>, as we only got one<br>
&gt; reply so far on the topic.<br>
<br>
I was hoping for some additional opinions here before adding my own, but <b=
r>
since this does not appear to happen, adding my personal opinion on this <b=
r>
matter now:<br>
<br>
*Some* property name being completely incompatible with =E2=80=9Cclone with=
=E2=80=9D (no <br>
matter how the first parameter is going to be called) is a limitation <br>
that should not exist, it feels like a feature that is broken by design <br=
>
and I think I really would hate it if the documentation of this RFC <br>
would need a =E2=80=9CCaution: It is not possible to reassign a property ca=
lled <br>
&#39;$object&#39;, due to a parameter name conflict=E2=80=9D.<br>
<br>
Adjusting the signature to `clone(object $object, array <br>
$withProperties)` would not have this problem and I don&#39;t consider the =
<br>
additional verbosity of an array literal to be a problem. Static <br>
analysis tools already understand array shapes and would need <br>
adjustments either way to understand the semantics.<br>
<br>
=C2=A0From an implementation PoV a regular array parameter would also be <b=
r>
simpler, since the implementation would be able to simply pass along the <b=
r>
input array, whereas the =E2=80=9Cvariadic=E2=80=9D syntax needs special ha=
ndling to <br>
combine positional parameters with named parameters into a single array <br=
>
that is then used in the cloning process.<br>
<br>
Syntax-wise there might also be a middle-ground. Similarly to how this <br>
RFC turns `clone()` into a function, the `array()` syntax also looks <br>
like a function call and would naturally extend to named parameters. <br>
While mixing positional and named parameters would probably get complex, <b=
r>
allowing purely named parameters would trivially be possible (without <br>
any function call overhead). It would also allow using the <br>
first-class-callable syntax with `array(...)`, something I would liked <br>
to have in the past. A proof of concept PR is at:<br>
<br>
<a href=3D"https://github.com/php/php-src/pull/18613" rel=3D"noreferrer" ta=
rget=3D"_blank">https://github.com/php/php-src/pull/18613</a><br>
<br>
Combining named-parameter `array()` syntax with clone taking a array as <br=
>
the second parameter would allow for the following, which might combine <br=
>
the best of both worlds?<br>
<br>
=C2=A0 =C2=A0 =C2=A0clone($obj, array(foo: 1, bar: &quot;baz&quot;, object:=
 &quot;this is not <br>
blocked&quot;));<br>
<br></blockquote><div><br></div><div><br></div><div>Thanks for sharing your=
 insights. This looks a bit far reaching for the RFC.</div><div><br></div><=
div>On my side, my opinion is: don&#39;t make clone a function call. I&#39;=
ve never missed not being able to call clone as a callback. It&#39;s trivia=
l to write a short function using the operator when in need.</div><div><br>=
</div><div>Nicolas</div></div></div>

--000000000000a85cf50635a62978--