Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120067
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-372-g43825cb665-fm-20230411.003-g43825cb6
Mime-Version: 1.0
Message-ID: <687944e3-75ec-446b-bbd6-6d3d6856e864@app.fastmail.com>
In-Reply-To: 
 <CAAwdEzCuLLd3uc-1Q+PaMW2PkJcg=KoP89vG+NXn5W3o+bvqFw@mail.gmail.com>
References: 
 <CAH5C8xUn2wotLg0L7KZHoOGf3q-UqbL=47p2PLzK_mOBb=MJXQ@mail.gmail.com>
 <CAAwdEzCuLLd3uc-1Q+PaMW2PkJcg=KoP89vG+NXn5W3o+bvqFw@mail.gmail.com>
Date: Tue, 18 Apr 2023 15:45:46 +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, Apr 17, 2023, at 7:43 AM, Alexandru P=C4=83tr=C4=83nescu wrote:
> On Mon, Apr 17, 2023, 07:32 M=C3=A1t=C3=A9 Kocsis <kocsismate90@gmail.=
com> wrote:
>
>> finally I managed to create a working implementation for this feature=
 which
>> would make it possible to properly modify readonly properties
>> while simplifying how we write "wither" methods:
>> https://wiki.php.net/rfc/clone_with

A solid RFC, thanks!

I agree with the discussion of Nicolas's alternative, which has its meri=
ts but also some possible limitations.  My only major concern myself is =
the potential confusion between when to use : and when to use =3D>.  Usi=
ng the =3D> version only for dynamic keys feels very clunky.  In fact, I=
 think the RFC is inconsistent on this front:

$object =3D clone $object with {"foo" =3D> 1}; // the property name is a=
 literal
$object =3D clone $object with {strtolower("FO") . "o" =3D> 1}; // the p=
roperty name is an expression
$object =3D clone $object with {PROPERTY_NAME =3D> 1}; // the property n=
ame is a named constant

I would expect the first one to be a colon, not fat-arrow.  Is that a ty=
po?

Is there a technical reason why they can't just all use a colon?  That w=
ould extend more nicely to supporting dynamic keys in the future for nam=
ed arguments.

> Hey M=C3=A1t=C3=A9,
>
> How about just allowing a block of code after the clone statement that
> would execute it in the same context as the clone context, allowing to
> modify once readonly variables.
> Allows better flexibility compared with clone with syntax or clone met=
ho:
>
>     public function withStatus($code, $reasonPhrase =3D ''): Response
>     {
>         return clone $this {
>             $this->statusCode =3D $code;
>
>            $this->reasonPhrase =3D $reasonPhrase;
>
> };

This is an interesting alternative.  I don't think $this is that confusi=
ng, actually.  Inside __clone(), $this always refers to the new object. =
 This proposal would essentially be providing an additional __clone bloc=
k that runs in the same context, viz, $this always refers to the new obj=
ect.  I'm not sure if you need the original object separately at all, in=
 fact; if you want to look up a value from the original object... you al=
ready have it on the new object in the same location, because it's a clo=
ne.  So:

public function withStatus($code, $reasonPhrase =3D ''): Response
{
    return clone $this {
        $this->statusCode =3D $code;
         $this->reasonPhrase =3D "Old: $this->reasonPhrase, New: $reason=
Phrase";
    }
};

$this->reasonPhrase in the string refers to the cloned object, where tha=
t value is by definition identical to the original object.  It's evaluat=
ed, the string is computed, and then the clone's reasonPhrase property i=
s updated.

The catch here is 2 fold:

1. This would essentially imply auto-capture.  While I am quite OK with =
that, a fair number of people are not.  But adding a use() block to that=
 syntax just makes it very clunky for the obvious common case; which is =
basically the above, so it just forces you to repeat each variable name =
a third time.  I would probably vote against something that forced more =
redundant use() statements.

2. The scope permissioning becomes weirder.  The current RFC syntax is v=
ery predictable: properties get assigned from the context at which the c=
lone statement lives, and if there are private/protected restrictions th=
ose are self-evident.  With the more closure-like approach, it "feels" l=
ike you're providing an anon function that will get bound to the new obj=
ect and then executed... which would then always run with private scope =
and be able to modify values you probably didn't want to be publicly mod=
ifiable.  While we could potentially implement it such that the scope ru=
les are still enforced, that may not be as obvious why you can/can't mes=
s with a particular variable.

I'm open to this alternative though if Mate is; it has potential, but we=
'd have to sort out the above.

--Larry Garfield