Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120467
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-447-ge2460e13b3-fm-20230525.001-ge2460e13
Mime-Version: 1.0
Message-ID: <5db38bc4-a6fd-4cb7-b10d-3ad1a590888c@app.fastmail.com>
In-Reply-To: 
 <CAH5C8xVhiByYaRqF8nKqj=m=xanPt=WDOPOy0Rt3G48pNutJ6Q@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>
Date: Tue, 30 May 2023 16:37:19 +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 Mon, May 29, 2023, at 11:22 PM, M=C3=A1t=C3=A9 Kocsis wrote:
> Hi Micha=C5=82 and Larry,
>
> As Tim has already clarified, using literal strings in the left-hand s=
ide
> of "clone with expressions" won't cause any issues
> for IDEs and static analysers to identify the correct property. I got =
rid
> of the shorthand syntax from the proposal because
> it is not strictly required (since it has an equivalent alternative), =
and I
> acknowledge the fact that there are certain people
> who don't want to have two syntaxes to express the same thing. If it t=
urns
> out that we really want to have the short-hand
> syntax as well, we can always add support for it later.

My point is, rather, that if we want to avoid having multiple syntaxes (=
which is valid), the existing named-args syntax and behavior already mor=
e than adequately covers all bases.

> That approach, taken now, gives us all the flexibility people have been
>> asking for, reuses the existing named arguments syntax entirely, and =
is the
>> most refactorable option.
>>
>
> Your suggestion is very interesting/promising... However, I'm a bit wo=
rried
> that if I only supported the "identifier: expression" syntax for
> "clone assignments", and I required people to pass an array (or splatt=
ed
> array) instead of the "expression =3D> expression" syntax,
> they would start complaining why they cannot directly use expressions =
as
> property names... That's why I think all the alternatives are useful
> on their own, but only the "expressions =3D> expression" syntax is
> vital, since all the other use-cases can be written like this.

Has the "if you need a variable name/number, use an array" been a proble=
m for named arguments?  I've not seen it been one.  Has anyone else?

You cannot use an expression as a function argument name today, and... n=
o one seems to mind.  Using an array in that rare edge case is fine.

I think we agree that the most common case by far will be a fixed, small=
 set of statically-named properties.  So we should optimize for that cas=
e, which is the named-args style.

>> Additionally, the current "property names expression" section shows a=
 very
>> odd example.  It's recloning the object N times, reinvoking the __clo=
ne
>> method each time, and reassigning a single property.  If you're updat=
ing
>> several properties at once, that is extremely inefficient.  Dynamic
>> property names are not the solution there; allowing the list to be dy=
namic
>> in the first place is, and that should not be punted to future scope.
>>
>
> I'm aware that it's currently inefficient, but it's the case only when=
 you
> want to update a dynamic list of properties. In my opinion, you update
> a fixed set of properties most of the time
> (e.g. Psr\Http\Message\ResponseInterface::withStatus()), and it's only=
 a
> rare case when you need
> more dynamic behavior. That's why I believe it's not a huge problem to=
 keep
> cloning objects unnecessarily until we add support for the stuff
> mentioned in the future scope section.

Except that named-args style gives us the better alternative today, with=
 known, pre-existing syntax and semantics.

> I am also confused by the choice to make __clone() run before with with
>> properties.  I would have expected it to be the other way around.  Ca=
n you
>> explain (in the RFC) why you did it that way?  That seems more limiti=
ng
>> than the alternative, as you cannot forward-pass information to __clo=
ne()
>> this way.
>>
>
> To be honest, the current behavior seemed like the natural choice for
> me, and I didn't really consider to execute the __clone() method after=
 the
> clone assignments.
> Do you have a use-case in mind when you need to forward-pass informati=
on to
> __clone()?

Not a specific one off hand.  It's more a conceptual question.  `with` h=
as more contextual awareness than __clone(), so it should have "first cr=
ack" at the operation, so that if necessary it can make changes that __c=
lone() can then respond to.  The inverse doesn't make sense.

The only reason for `with` to come after would be to allow `with` to "ov=
erride" or "undo" something that __clone() did.  Generally speaking, if =
you have to undo something you just did, you shouldn't have done it in t=
he 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.

--Larry Garfield