Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115207
MIME-Version: 1.0
References: <CAF+90c-W_g9Mt9yMNzBWfMEmQP287a7A6S75RyZo2fvUO2uGXQ@mail.gmail.com>
 <CAF+90c8eE_J-ntY=E8rtusAzh_6mJUKRmYhtunyAV2dPK7LN5Q@mail.gmail.com>
 <CAOWwgpkiMhrQ-zyww8G4aSEcVgKwsr=sagoEZb1r5fszvgOsmA@mail.gmail.com>
 <24af2d01-4f6c-4389-a35a-dab50c0b5e66@www.fastmail.com> <CAOWwgp=-QYogyVdpB+2FN858rgyDk3DwoYqGWnhP3D=L9XaS1A@mail.gmail.com>
 <CAOWwgpm5XL5fEDtZbF+Z3hiUSfJ=hacpUr+6-_DJkGL3VAWpDg@mail.gmail.com> <CAOWwgpnvX=1f-zzCpOPzu8az3cfiu_vD-Ez0=o8jT=KpfzbHTw@mail.gmail.com>
In-Reply-To: <CAOWwgpnvX=1f-zzCpOPzu8az3cfiu_vD-Ez0=o8jT=KpfzbHTw@mail.gmail.com>
Date: Tue, 29 Jun 2021 15:08:33 +0200
Message-ID: <CAF+90c8cth1D3XP32L_MTWBLpMC736b9nq-ds7rHa=P+ydbPJA@mail.gmail.com>
To: Nicolas Grekas <nicolas.grekas+php@gmail.com>
Cc: Larry Garfield <larry@garfieldtech.com>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000094a7c205c5e74ee1"
Subject: Re: [PHP-DEV] Re: [RFC] Readonly properties
From: nikita.ppv@gmail.com (Nikita Popov)

--00000000000094a7c205c5e74ee1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 29, 2021 at 9:14 AM Nicolas Grekas <nicolas.grekas+php@gmail.co=
m>
wrote:

> Le lun. 28 juin 2021 =C3=A0 18:22, Larry Garfield <larry@garfieldtech.com=
> a
>>> =C3=A9crit :
>>>
>>>> On Mon, Jun 28, 2021, at 11:17 AM, Nicolas Grekas wrote:
>>>> > > > I'd like to open the discussion on readonly properties:
>>>> > > > https://wiki.php.net/rfc/readonly_properties_v2
>>>> > > >
>>>> > > > This proposal is similar to the
>>>> > > > https://wiki.php.net/rfc/write_once_properties RFC that has been
>>>> > > declined
>>>> > > > previously. One significant difference is that the new RFC limit=
s
>>>> the
>>>> > > scope
>>>> > > > of initializing assignments. I think a key mistake of the
>>>> previous RFC
>>>> > > was
>>>> > > > the confusing "write-once" framing, which is both technically
>>>> correct and
>>>> > > > quite irrelevant.
>>>> > > >
>>>> > > > Please see the rationale section (
>>>> > > > https://wiki.php.net/rfc/readonly_properties_v2#rationale) for
>>>> how this
>>>> > > > proposal relates to other RFCs and alternatives.
>>>> > > >
>>>> > >
>>>> > > I plan to open voting on this RFC soon. I don't think there's
>>>> anything
>>>> > > technical left to address here, the discussion mostly comes down t=
o
>>>> a value
>>>> > > judgement. I think everyone has made their position regarding that
>>>> clear...
>>>> > >
>>>> >
>>>> > Actually, we talked off the list about a way to possibly make this
>>>> work
>>>> > with __clone():
>>>> >
>>>> > We could allow __clone to have one argument, the object being cloned=
.
>>>> And
>>>> > when the signature declares this argument, then all readonly
>>>> properties
>>>> > would be set as uninitialized on $this.
>>>> >
>>>> > A typical __clone function would look like this with readonly
>>>> properties:
>>>> > function __clone(object $original)
>>>> > {
>>>> >     $this->readonlyProp =3D clone $original->readonlyProp;
>>>> > }
>>>> >
>>>> > That would turn my vote into a +1 if that could be made to work!
>>>>
>>>> That sounds like it would support deep cloning, but not with-er
>>>> methods.  There's no way to provide a changed value.  It also would me=
an a
>>>> lot of work on larger objects to transfer across all the properties.  =
I
>>>> don't really see what this would add.
>>>>
>>>
>>> Can you elaborate about the lack of support for withers? Having some
>>> work to do doesn't look like an issue to me, especially when there is n=
o
>>> alternative to compare that too.
>>>
>>
>> I sent that too fast, I agree about withers... :)
>> I'm looking for a way to +1 that RFC...
>> Any other idea?
>>
>
> And I was too fast agreeing that my proposal to pass the original object
> as argument was incompatible with withers.
>
> I also think that not being compatible with deep cloning is a major issue=
.
> Past trivial cases, the use cases I can think of where I would use readon=
ly
> require deep cloning. See eg the Symfony Request object where query param=
s,
> headers, and a few others expose state as public objects.
>
> Here is some code that just works with them:
> class C
> {
>     public readonly string $foo;
>     public readonly string $bar;
>
>     private $skipWhenCloning;
>
>     public function withFoo($foo)
>     {
>         $this->skipWhenCloning =3D 'foo';
>         $clone =3D clone $this;
>         $clone->foo =3D $foo;
>     }
>
>     public function withBar($bar)
>     {
>         $this->skipWhenCloning =3D 'bar';
>         $clone =3D clone $this;
>         $clone->bar =3D $bar;
>     }
>
>     public function __clone(self $original)
>     {
>         foreach ($this as $k =3D> $v) {
>             if ($k !=3D=3D $this->skipWhenCloning) {
>                 $this->$k =3D $original->$k;
>             }
>         }
>         $this->skipWhenCloning =3D $original->skipWhenCloning =3D null;
>     }
> }
>
> You might not like the boilerplate, but that just works.
>
> Can this be considered Nikita?
>

Well, it's a nifty hack :) I don't think this is the solution we want to
encourage though. It requires you pass extra information through a
side-channel -- I think I'd rather not use readonly than write that code.

Continuing along the same line, one could extend that to "clone with
argument" and do something like this:

public function __clone(self $original, array $replacements =3D []) {
    foreach ($original as $k =3D> $v) {
        $this->$k =3D $replacements[$k] ?? $original->$k;
    }
}

and then do "clone $this(['bar' =3D> $bar])".

In any case, I don't want to include changes to cloning in this proposal --
the topic is related, but also orthogonal to readonly properties.
Unfortunately, it will not be possible to get cloning changes into PHP 8.1
anymore, due to feature freeze.

It's okay to vote against this if cloning is a deal breaker. In that case
I'll probably either work on cloning before re-proposing this, or pivot to
asymmetric visibility -- it's not my first preference, but it may be the
more pragmatic choice. Cloning is definitely the weak point of this
proposal.

Regards,
Nikita

--00000000000094a7c205c5e74ee1--