Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112675
MIME-Version: 1.0
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 18:42:56 +0000
Message-ID: <CAJpLVh2oenSMij4NkGGXL5O5iY14bRCgMnrELJKxAf-bhS9wYw@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: 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:15 GMT, Rowan Tommins <rowan.collins@gmail.com>:
> 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/uni=
que
>> $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);

Sure, this is a good use-case for immutability. :)

>
>
> 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);

Using a variable on right-hand side does not automatically create an
alias, so in the above case you don't have to use clone.

A more motivating example for uniqueness is perhaps a query builder.

```
$query =3D (new Query())
  ->select(1)
  ->from('foo')
  ->where(...)
  ->orderBy(..)
  ->limit();
doSomething($query);
doSomethingElse($query);
```

In the above snippet, we don't know if doSomething() will change
$query and cause a bug. The issue can be solved with an immutable
builder, using withSelect(), withWhere(), etc, OR it's solved with
uniqueness, forcing a clone to avoid creating a new alias (passing
$query to a function creates an alias inside that function). The
optimisation is the same as in my previous example, avoiding copying
$query multiple times during build-up.

>
>
>> 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.
>
>
> I wonder if that difference can be optimised out by the
> compiler/OpCache: detect clones that immediately replace their original,
> and optimise it to an in-place modification. In other words, compile
> $foo =3D clone $foo with { x: 42 } to $foo->x =3D 42, even if the clone i=
s
> actually in a "withX" method.

I guess OCaml/Haskell does stuff like this, since everything is
immutable by default there. Let's ask them? Unless someone here
already knows? :)

Olle