Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127420
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Wed, 21 May 2025 23:27:48 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <9aa91498-b224-4a46-8c7e-21ae8a9c58a7@app.fastmail.com>
In-Reply-To: <2f30cae4add309021e18d0f359a1814e@bastelstu.be>
References: 
 <CAMzRQTdePFXUMWO38g=gQA2vbqL5zp=o1cPt00ec41g95xys=g@mail.gmail.com>
 <CAMzRQTe_vn1a-ji9M2NXnBgJm3eHOGTHozWpM1jGzOht_sNs4w@mail.gmail.com>
 <2f30cae4add309021e18d0f359a1814e@bastelstu.be>
Subject: Re: [PHP-DEV] Re: [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 21, 2025, at 9:13 AM, Tim D=C3=BCsterhus wrote:
> Hi
>
> Am 2025-05-19 12:48, schrieb Volker Dusch:
>> We're still looking for feedback on the ...variadic approach to the=20
>> 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, b=
ut=20
> since this does not appear to happen, adding my personal opinion on th=
is=20
> matter now:
>
> *Some* property name being completely incompatible with =E2=80=9Cclone=
 with=E2=80=9D (no=20
> matter how the first parameter is going to be called) is a limitation=20
> that should not exist, it feels like a feature that is broken by desig=
n=20
> and I think I really would hate it if the documentation of this RFC=20
> would need a =E2=80=9CCaution: It is not possible to reassign a proper=
ty called=20
> '$object', due to a parameter name conflict=E2=80=9D.

I completely disagree here.  The __ prefix is sufficient to solve the is=
sue.  A double underscore prefix has been understood to mean "internal t=
o PHP, magic here" for at least 20 years.  The chances of someone having=
 a property called $__object are virtually nil, and if they do, they're =
already treading on naming that's reserved for PHP's use anyway so if it=
 breaks, it's their own fault.

> Adjusting the signature to `clone(object $object, array=20
> $withProperties)` would not have this problem and I don't consider the=20
> additional verbosity of an array literal to be a problem. Static=20
> analysis tools already understand array shapes and would need=20
> adjustments either way to understand the semantics.
>
>  From an implementation PoV a regular array parameter would also be=20
> simpler, since the implementation would be able to simply pass along t=
he=20
> input array, whereas the =E2=80=9Cvariadic=E2=80=9D syntax needs speci=
al handling to=20
> combine positional parameters with named parameters into a single arra=
y=20
> that is then used in the cloning process.
>
> Syntax-wise there might also be a middle-ground. Similarly to how this=20
> RFC turns `clone()` into a function, the `array()` syntax also looks=20
> like a function call and would naturally extend to named parameters.=20
> While mixing positional and named parameters would probably get comple=
x,=20
> allowing purely named parameters would trivially be possible (without=20
> any function call overhead). It would also allow using the=20
> first-class-callable syntax with `array(...)`, something I would liked=20
> 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 a=
s=20
> the second parameter would allow for the following, which might combin=
e=20
> the best of both worlds?
>
>      clone($obj, array(foo: 1, bar: "baz", object: "this is not=20
> blocked"));

I completely disagree here as well.  I actively dislike using an array h=
ere, as I do find quoting all the keys to be cumbersome.  And I don't th=
ink we should go with a worse syntax in the hopes of it being improved l=
ater, when there may well be other unforeseen challenges there.  (Eg, I =
have no idea if bare array keys would cause issues with constants.)  Mor=
eover, we have 15 years of training and coding standards and automation =
tools that say to never use array(), always [].  Reversing that would be=
 far more disruptive for the ecosystem, even if it turns out to be not t=
oo disruptive to the code.

I strongly prefer the current syntax, and if the RFC changed to require =
an array I would strongly consider voting No on those grounds alone.

--Larry Garfield