Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127461
Precedence: bulk
MIME-Version: 1.0
References: <CAMzRQTdePFXUMWO38g=gQA2vbqL5zp=o1cPt00ec41g95xys=g@mail.gmail.com>
 <CAMzRQTe_vn1a-ji9M2NXnBgJm3eHOGTHozWpM1jGzOht_sNs4w@mail.gmail.com> <CAMzRQTe-moWS4acwUHesA=K_pb+z+J8H_aMHCesyZL3qjG7z-g@mail.gmail.com>
In-Reply-To: <CAMzRQTe-moWS4acwUHesA=K_pb+z+J8H_aMHCesyZL3qjG7z-g@mail.gmail.com>
Date: Mon, 26 May 2025 16:37:37 +0200
Message-ID: <CAOWwgpkO8VasKSP5QMC0kwN58OihdTc+JeQ_s_XsNnJBZz9E7w@mail.gmail.com>
Subject: Re: [PHP-DEV] Re: [RFC] Clone with v2
To: Volker Dusch <volker@tideways-gmbh.com>
Cc: php internals <internals@lists.php.net>, =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Content-Type: multipart/alternative; boundary="0000000000006038a206360ae454"
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--0000000000006038a206360ae454
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Volker,

Thanks for the update.

Le lun. 26 mai 2025 =C3=A0 16:05, Volker Dusch <volker@tideways-gmbh.com> a
=C3=A9crit :

> Version 1.1 Update: Array syntax over named arguments.
>
> Thank you everyone for the discussion and for improving this RFC. I'm ver=
y
> happy with the updates we made thanks to your feedback on and off list.
>
> The main idea of this RFC was to have as little of a footprint as possibl=
e
> and make it feel natural in PHP. I got carried away a bit during writing
> this, and by using named arguments, introduced something that isn't used =
in
> php-src provided functions, had edge cases that required documentation, a=
nd
> all in all, didn't feel natural in PHP but like an inconsistency. PHP use=
s
> arrays to pass lists everywhere else, so changing this here feels like to=
o
> much scope for this little change. I'm very happy this was caught and
> raised in the discussions. Thank you.
>
> If there is desire for named-parameter-as-an-array syntax this should be
> standalone RFC with more scope than a single function.
>
> We've updated the RFC and the implementation, removing the "Open Issue"
> listed before, as this change resolved all of them.
>
> - https://wiki.php.net/rfc/clone_with_v2
> - https://github.com/TimWolla/php-src/pull/6
>


To me, it would have made more sense  to still make "clone" an operator but
I think we can all get used to the array style, so if the majority thinks
arrays should be the way to go, so be it.

I think the RFC is missing a few bits to be complete:

- making "clone" a function means suddenly a "use clone;" or a "\clone" is
going to be needed to not get a perf hit, isn't it? But since $y =3D clone
$x; is still going to be valid, how will this be handled? The RFC could
give some more hints on the topic.

- writing code with a wide range of supported PHP versions means we'll
start using construct such as:
if (PHP_VERSION_ID>=3D80500) {
   $b =3D 'clone'($a, [...]); // note 'clone' is a string here, so that the
line is valid syntax on PHP <=3D 8.4
else {
   // another code path for PHP 8.4
}
That's of course because "use clone", "\clone" or "clone($foo)" is invalid
PHP syntax currently.
It could make sense to tell about this and show an example like this one in
the RFC.

- what if one gives a mangled property in the array? clone($foo,
["\0Foo\0bar" =3D> 123])
It could be useful to write something about this case and/or at least have
a test case that shows how this should behave.

- To me, the main technical drawback of the RFC is that it builds on
mandatory deep-cloning, which means wasted CPU/mem resources by design.
This has to be mentioned in the RFC IMHO so that voters can make an
informed decision.

About this last point, it's the one that makes me undecided about my voting
decision on the RFC.
I shared my concern and a solution in another thread, where I also address
the BC concern that is mentioned in the RFC. Since this concern has been
addressed, I think this should be considered more closely. As is, that's a
big omission to me - recognizing and addressing the issue with deep-cloning=
.

Cheers,
Nicolas

--0000000000006038a206360ae454
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div>Hi Volker,</div><div><br></div><div>=
Thanks for the update.</div></div><br><div class=3D"gmail_quote gmail_quote=
_container"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0lun. 26 mai 2025 =
=C3=A0=C2=A016:05, Volker Dusch &lt;<a href=3D"mailto:volker@tideways-gmbh.=
com">volker@tideways-gmbh.com</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"=
>Version 1.1 Update: Array syntax over named arguments.<br></div><div dir=
=3D"ltr"><br></div><div>Thank you everyone for the discussion and for impro=
ving this RFC. I&#39;m very happy with the updates we made thanks to your f=
eedback on and off list.</div><div><br></div><div>The main idea of this RFC=
 was to have as little of a footprint as=C2=A0possible and make it feel nat=
ural in PHP. I got carried away a bit during writing this, and by using nam=
ed arguments, introduced something that isn&#39;t used in php-src provided =
functions, had edge cases that required documentation, and all in all, didn=
&#39;t feel natural in PHP but like an inconsistency. PHP uses arrays to pa=
ss lists everywhere else, so changing this here feels like too much scope f=
or this little change. I&#39;m very happy this was caught and raised in the=
 discussions. Thank you.</div><div><br></div><div>If there is desire for na=
med-parameter-as-an-array syntax this should be standalone RFC with more sc=
ope than a single function.</div><div><br></div><div>We&#39;ve updated=C2=
=A0the RFC and the implementation, removing the &quot;Open Issue&quot; list=
ed before, as this change resolved all of them.</div><div><br></div><div>-=
=C2=A0<a href=3D"https://wiki.php.net/rfc/clone_with_v2" target=3D"_blank">=
https://wiki.php.net/rfc/clone_with_v2</a></div><div>-=C2=A0<a href=3D"http=
s://github.com/TimWolla/php-src/pull/6" target=3D"_blank">https://github.co=
m/TimWolla/php-src/pull/6</a></div></div></blockquote><div><br></div><div><=
br></div><div>To me, it would have made more sense=C2=A0 to still make &quo=
t;clone&quot; an operator but I think we can all get used to the array styl=
e, so if the majority thinks arrays should be the way to go, so be it.</div=
><div><br></div><div>I think the RFC is missing a few bits to be complete:<=
/div><div><br></div><div>- making &quot;clone&quot; a function means sudden=
ly a &quot;use clone;&quot; or a &quot;\clone&quot; is going to be needed t=
o not get a perf hit, isn&#39;t it? But since $y =3D clone $x; is still goi=
ng to be valid, how will this be handled? The RFC could give some more hint=
s on the topic.</div><div><br></div><div>- writing code with a wide range o=
f supported PHP versions means we&#39;ll start using construct such as:</di=
v><div>if (PHP_VERSION_ID&gt;=3D80500) {</div><div>=C2=A0=C2=A0 $b =3D &#39=
;clone&#39;($a, [...]); // note &#39;clone&#39; is a string here, so that t=
he line is valid syntax on PHP &lt;=3D 8.4</div><div>else {</div><div>=C2=
=A0=C2=A0 // another code path for PHP 8.4</div><div>}</div><div>That&#39;s=
 of course because &quot;use clone&quot;, &quot;\clone&quot; or &quot;clone=
($foo)&quot; is invalid PHP syntax currently.</div><div>It could make sense=
 to tell about this and show an example like this one in the RFC.</div><div=
><br></div><div>- what if one gives a mangled property in the array? clone(=
$foo, [&quot;\0Foo\0bar&quot; =3D&gt; 123])</div><div>It could be useful to=
 write something about this case and/or at least have a test case that show=
s how this should behave.</div><div><br></div><div>- To me, the main techni=
cal drawback of the RFC is that it builds on mandatory deep-cloning, which =
means wasted  CPU/mem resources by design. This has to be mentioned in the =
RFC IMHO so that voters can make an informed decision.</div><div><br></div>=
<div>About this last point, it&#39;s the one that makes me undecided about =
my voting decision on the RFC.</div><div>I shared my concern and a solution=
 in another thread, where I also address the BC concern that is mentioned i=
n the RFC. Since this concern has been addressed, I think this should be co=
nsidered more closely. As is, that&#39;s a big omission to me - recognizing=
 and addressing the issue with deep-cloning.</div><div><br></div><div>Cheer=
s,</div><div>Nicolas</div></div></div>

--0000000000006038a206360ae454--