Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115186
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>
In-Reply-To: <CAOWwgp=-QYogyVdpB+2FN858rgyDk3DwoYqGWnhP3D=L9XaS1A@mail.gmail.com>
Date: Mon, 28 Jun 2021 20:36:42 +0200
Message-ID: <CAOWwgpm5XL5fEDtZbF+Z3hiUSfJ=hacpUr+6-_DJkGL3VAWpDg@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000106b6805c5d7c6d3"
Subject: Re: [PHP-DEV] Re: [RFC] Readonly properties
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--000000000000106b6805c5d7c6d3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Le lun. 28 juin 2021 =C3=A0 20:30, Nicolas Grekas <nicolas.grekas+php@gmail=
.com>
a =C3=A9crit :

>
>
> 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 limits
>> 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 anythi=
ng
>> > > technical left to address here, the discussion mostly comes down to =
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 wor=
k
>> > with __clone():
>> >
>> > We could allow __clone to have one argument, the object being cloned.
>> And
>> > when the signature declares this argument, then all readonly propertie=
s
>> > 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 mean 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 no
> 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?

--000000000000106b6805c5d7c6d3--