Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112676
MIME-Version: 1.0
In-Reply-To: <3e683903-66cb-4a1a-9ff8-22887dbb8dce@www.fastmail.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> <3e683903-66cb-4a1a-9ff8-22887dbb8dce@www.fastmail.com>
Date: Wed, 30 Dec 2020 18:45:05 +0000
Message-ID: <CAJpLVh1o+BmqzEN_ewQVxEoNoe1caUYHJ7QB8LTBAeu2f889fA@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Analysis of property visibility, immutability, and
 cloning proposals
From: olleharstedt@gmail.com (=?UTF-8?Q?Olle_H=C3=A4rstedt?=)

2020-12-30 18:31 GMT, Larry Garfield <larry@garfieldtech.com>:
> 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;
>> > ```
>>
>>
>> Thanks, I can see how that solves a lot of the same problems, in a very
>> robustly analysable way.
>>
>> However, from a high-level user-friendliness point of view, I think
>> "withX" methods are actually more natural than explicitly cloning
>> mutable objects.
>>
>> Consider the case of defining a range: firstly, with plain integers and
>> familiar operators:
>>
>> $start =3D 1;
>> $end =3D $start + 5;
>>
>> This models integers as immutable values, and + as an operator which
>> returns a new instance. If integers were mutable but not aliasable, we
>> would instead write something like this:
>>
>> $start =3D 1;
>> $end =3D clone $start;
>> $end +=3D 5; // where +=3D would be an in-place modification, not a
>> short-hand for assignment
>>
>> I think the first more naturally expresses the desired algorithm. It's
>> therefore natural to want the same for a range of dates:
>>
>> $start =3D MyDate::today();
>> $end =3D $start->withAddedDays(5);
>>
>> vs
>>
>> $start =3D MyDate::today();
>> $end =3D clone $start;
>> $end->addDays(5);
>>
>>
>> To put it a different way, value types naturally form *expressions*,
>> which mutable objects model clumsily. It would be very tedious if we had
>> to avoid accidentally mutating the speed of light:
>>
>> $e =3D (clone $m) * ((clone $c) ** 2);
>>
>>
>> > 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
> equivalent) 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 up som=
e,
> but far less than you think.  (Again, based on the tests MWOP ran for PSR=
-7
> a ways back.)

I thought copy-on-write was only for arrays, not objects?

Olle