Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115262
User-Agent: Cyrus-JMAP/3.5.0-alpha0-530-gd0c265785f-fm-20210616.002-gd0c26578
Mime-Version: 1.0
Message-ID: <ef044022-0f12-4518-9b46-1fd54faee0f4@www.fastmail.com>
In-Reply-To: <c3a82f3c-2aa4-4e71-faca-782757167166@processus.org>
References: 
 <CAF+90c9kZMwjUupnCJ+Ak3SKtQSC3Mb3GTcVJWUfYG6BDkbKPA@mail.gmail.com>
 <CAOWwgpmYRgfBWxvH7j0984rSXKDM_i3jEmwo+A7=MHCa=da5BQ@mail.gmail.com>
 <c3a82f3c-2aa4-4e71-faca-782757167166@processus.org>
Date: Thu, 01 Jul 2021 10:25:18 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [VOTE] Readonly properties
From: larry@garfieldtech.com ("Larry Garfield")

On Thu, Jul 1, 2021, at 9:49 AM, Pierre wrote:
> Le 01/07/2021 =C3=A0 16:38, Nicolas Grekas a =C3=A9crit=C2=A0:
> > Hi NIkita,
> >
> > I voted against the proposal because it doesn't work with cloning at=
 all.
> >
> > Cloning is a critical feature of stateful objects, and we should sol=
ve it
> > the same version that introduces readonly IMHO.
> >
> > If we figure out that we can't agree on a sensible improved behavior=
 for
> > cloning, we're going to be in a dead-end with readonly.
> >
> I respectfully disagree.
>=20
> Having readonly properties and immutable objects is a must have, but=20=

> changing property of an object while cloning, not so much. There's man=
y=20
> case where readonly properties will be valuable where you never need t=
o=20
> clone your objects. Actually, cloning objects is not something you do=20=

> every day.
>=20
> Please note that I agree with you that advanced / flexible clone=20
> semantics would be a nice to have, but I don't see the lack of it=20
> blocking for readonly properties.
>=20
> I personally don't have any real use case where I couldn't implement=20=

> withers on my objects doing the same than dedicated advanced clone=20
> semantics. Could you please provide some real world examples ? People=20=

> could change their minds if they could see why it's so blocking for yo=
u.
>=20
> Regards,

The most famous use case right now for with-er objects is PSR-7, which i=
s where the naming convention comes from.  I cannot say how widely used =
it is outside of FIG-inspired value objects, but I am pretty sure it is =
used.

The key point is that you rarely need to clone service objects; value ob=
jects, however, you have to clone if you want to mutate.  Look at any PS=
R-7 pipleline.  By design, it calls $request->withBlah($newBlah) a lot, =
and returns a new object.  That's the model that we want to support, and=
 make *easier* to do, but the readonly flag makes *harder* to do than th=
e status quo today.  (See my previous post on the subject in the last th=
read.)

There are use cases for readonly that don't require cloning.  For those,=
 it's useful.  I personally think asymmetric visibility would render rea=
donly unnecessary and redundant, but Nikita disagrees, and he's the one =
writing the code so... :-)

The best case scenario is by 8.2 we end up with asymmetric visibility an=
d clone-with, and combined with readonly we get a huge array of options =
for how to lock down value objects and still make them evolvable.  The w=
orst case scenario is we find that readonly cannot be extended to suppor=
t clone-with for some hand-wavy engine reasons, at which point it become=
s largely vestigial in favor of asymmetric visibility and clone-with.

--Larry Garfield