Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112673
User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396
Mime-Version: 1.0
Message-ID: <3e683903-66cb-4a1a-9ff8-22887dbb8dce@www.fastmail.com>
In-Reply-To: <7f4fe9ca-1c20-6f69-cef0-a9718af742a3@gmail.com>
References: <1d0abb04-4987-43a9-85bc-bccc3bd6be9a@www.fastmail.com>
 <03108284-740a-4a5d-130f-15b2e67e9df9@mabe.berlin>
 <CAJpLVh2M3iKhG8b2qZydf_70K4NYdZ5fpSEsRNK7uLeESUPHKg@mail.gmail.com>
 <459d7ff7-e553-dce9-7d43-c3b1e772e572@gmail.com>
 <CAJpLVh31UzSJvKdypQ=Mh+6CLvfUCrF==z6HBDD1_nuYqFzG5A@mail.gmail.com>
 <7f4fe9ca-1c20-6f69-cef0-a9718af742a3@gmail.com>
Date: Wed, 30 Dec 2020 12:31:09 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: =?UTF-8?Q?Re:_[PHP-DEV]_Analysis_of_property_visibility,_immutability,_a?=
 =?UTF-8?Q?nd_cloning_proposals?=
From: larry@garfieldtech.com ("Larry Garfield")

On Wed, Dec 30, 2020, at 12:15 PM, Rowan Tommins wrote:
> On 30/12/2020 13:49, Olle H=C3=A4rstedt wrote:
> > Uniqueness is when you only allow _one_ reference to an object (or
> > bucket of memory).
> > [...]
> >
> > You can compare a builder pattern with immutability vs non-aliasing
> > (uniqueness):
> >
> > ```
> > // Immutable
> > $b =3D new Builder();
> > $b =3D $b->withFoo()->withBar()->withBaz();
> > myfun($b);  // $b is immutable, so $b cannot be modified by myfun()
> > return $b;
> > ```
> >
> > ```
> > // Uniqueness
> > $b =3D new Builder();  // class Builder is annotated as non-aliasing=
/unique
> > $b->addFoo();
> > $b->addBar();
> > $b->addBaz();
> > myfun(clone $b);  // HAVE TO CLONE TO NOT THROW EXCEPTION.
> > return $b;
> > ```
>=20
>=20
> Thanks, I can see how that solves a lot of the same problems, in a ver=
y=20
> robustly analysable way.
>=20
> However, from a high-level user-friendliness point of view, I think=20=

> "withX" methods are actually more natural than explicitly cloning=20
> mutable objects.
>=20
> Consider the case of defining a range: firstly, with plain integers an=
d=20
> familiar operators:
>=20
> $start =3D 1;
> $end =3D $start + 5;
>=20
> This models integers as immutable values, and + as an operator which=20=

> returns a new instance. If integers were mutable but not aliasable, we=
=20
> would instead write something like this:
>=20
> $start =3D 1;
> $end =3D clone $start;
> $end +=3D 5; // where +=3D would be an in-place modification, not a=20=

> short-hand for assignment
>=20
> I think the first more naturally expresses the desired algorithm. It's=
=20
> therefore natural to want the same for a range of dates:
>=20
> $start =3D MyDate::today();
> $end =3D $start->withAddedDays(5);
>=20
> vs
>=20
> $start =3D MyDate::today();
> $end =3D clone $start;
> $end->addDays(5);
>=20
>=20
> To put it a different way, value types naturally form *expressions*,=20=

> which mutable objects model clumsily. It would be very tedious if we h=
ad=20
> to avoid accidentally mutating the speed of light:
>=20
> $e =3D (clone $m) * ((clone $c) ** 2);
>=20
>=20
> > The guarantee in both above snippets is that myfun() DOES NOT modify=

> > $b before returning it. BUT with immutability, you have to copy $b
> > three times, with uniqueness only one.

That's a good summary of why immutability and with-er methods (or some e=
quivalent) are more ergonomic.

Another point to remember: Because of PHP's copy-on-write behavior, full=
 on immutability doesn't actually waste that much memory.  It does use u=
p some, but far less than you think.  (Again, based on the tests MWOP ra=
n for PSR-7 a ways back.)

> I wonder if that difference can be optimised out by the=20
> compiler/OpCache: detect clones that immediately replace their origina=
l,=20
> and optimise it to an in-place modification. In other words, compile=20=

> $foo =3D clone $foo with { x: 42 } to $foo->x =3D 42, even if the clon=
e is=20
> actually in a "withX" method.

In concept, maybe?  That's well above my pay grade. :-)

--Larry Garfield