Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120441
MIME-Version: 1.0
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>
In-Reply-To: <280bcea8-9483-4191-80d3-81763a988290@app.fastmail.com>
Date: Tue, 30 May 2023 01:22:36 +0200
Message-ID: <CAH5C8xVhiByYaRqF8nKqj=m=xanPt=WDOPOy0Rt3G48pNutJ6Q@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000554d9205fcdd5d13"
Subject: Re: [PHP-DEV] [RFC] [Discussion] Clone with
From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)

--000000000000554d9205fcdd5d13
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Micha=C5=82 and Larry,

As Tim has already clarified, using literal strings in the left-hand side
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 turns
out that we really want to have the short-hand
syntax as well, we can always add support for it later.

Conversely, using the named arguments style syntax (what future scope calls
> a shorthand, which I don't think is accurate as it's nearly the same amou=
nt
> of typing)


I'm just using the same wording as Nikita used in his named argument RFC.
Please take a look at the following section:
https://wiki.php.net/rfc/named_params#shorthand_syntax_for_matching_paramet=
er_and_variable_name
Especially this sentence is important:

If I wanted to put these ideas into a general framework, I think one way to
> go about this would be as follows:
> - Consider identifier: $expr as a shorthand for "identifier" =3D> $expr.


Even though the shorthand syntax is only 4 characters shorter than the
normal one (including the missing space before the colon),
for a typical property name which may be 4-8 characters long (I guess),
it's a significant reduction of typing.

That approach, taken now, gives us all the flexibility people have been
> asking for, reuses the existing named arguments syntax entirely, and is t=
he
> most refactorable option.
>

Your suggestion is very interesting/promising... However, I'm a bit worried
that if I only supported the "identifier: expression" syntax for
"clone assignments", and I required people to pass an array (or splatted
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.


> Additionally, the current "property names expression" section shows a ver=
y
> odd example.  It's recloning the object N times, reinvoking the __clone
> method each time, and reassigning a single property.  If you're updating
> several properties at once, that is extremely inefficient.  Dynamic
> property names are not the solution there; allowing the list to be dynami=
c
> 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.

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.  Can yo=
u
> explain (in the RFC) why you did it that way?  That seems more limiting
> than the alternative, as you cannot forward-pass information to __clone()
> 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 information to
__clone()?

Regards,
M=C3=A1t=C3=A9

--000000000000554d9205fcdd5d13--