Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122901
Precedence: bulk
MIME-Version: 1.0
References: <CAPyj-LA7kJLdz3Pzbxr6x-7v2YV8n06pwxs6QoVe3CGgx-_GGA@mail.gmail.com>
 <d02a2d11-cbe3-4fef-9181-2fbac8988f34@rwec.co.uk>
In-Reply-To: <d02a2d11-cbe3-4fef-9181-2fbac8988f34@rwec.co.uk>
Date: Wed, 3 Apr 2024 01:01:58 +0200
Message-ID: <CAPyj-LA49UoAqtSekwxuMwHUv0FyAUdUtQ_m12dQTSDP-VQhLA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC][Concept] Data classes (a.k.a. structs)
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: tovilo.ilija@gmail.com (Ilija Tovilo)

Hi Rowan

On Tue, Apr 2, 2024 at 10:10=E2=80=AFPM Rowan Tommins [IMSoP]
<imsop.php@rwec.co.uk> wrote:
>
> On 02/04/2024 01:17, Ilija Tovilo wrote:
>
> I'd like to introduce an idea I've played around with for a couple of
> weeks: Data classes, sometimes called structs in other languages (e.g.
> Swift and C#).
>
> I'm not sure if you've considered it already, but mutating methods should=
 probably be constrained to be void (or maybe "mutating" could occupy the r=
eturn type slot). Otherwise, someone is bound to write this:
>
> $start =3D new Location('Here');
> $end =3D $start->move!('There');
>
> Expecting it to mean this:
>
> $start =3D new Location('Here');
> $end =3D $start;
> $end->move!('There');
>
> When it would actually mean this:
>
> $start =3D new Location('Here');
> $start->move!('There');
> $end =3D $start;

I think there are some valid patterns for mutating methods with a
return value. For example, Set::add() might return a bool to indicate
whether the value was already present in the set.

> I seem to remember when this was discussed before, the argument being mad=
e that separating value objects completely means you have to spend time dec=
iding how they interact with every feature of the language.

Data classes are classes with a single additional
zend_class_entry.ce_flags flag. So unless customized, they behave as
classes. This way, we have the option to tweak any behavior we would
like, but we don't need to.

Of course, this will still require an analysis of what behavior we
might want to tweak.

> Does the copy-on-write optimisation actually require the entire class to =
be special, or could it be triggered by a mutating method on any object? To=
 allow direct modification of properties as well, we could move the call-si=
te marker slightly to a ->! operator:
>
> $foo->!mutate();
> $foo->!bar =3D 42;

I suppose this is possible, but it puts the burden for figuring out
what to separate onto the user. Consider this example, which would
work with the current approach:

$shapes[0]->position->zero!();

The left-hand-side of the mutating method call is fetched by
"read+write". Essentially, this ensures that any array or data class
is separated (copied if RC >1).

Without such a class-wide marker, you'll need to remember to add the
special syntax exactly where applicable.

$shapes![0]!->position!->zero();

In this case, $shapes, $shapes[0], and $shapes[0]->position must all
be separated. This seems very easy to mess up, especially since only
zero() is actually known to be separating and can thus be verified at
runtime.

> The main drawback I can see (outside of the implementation, which I can't=
 comment on) is that we couldn't overload the =3D=3D=3D operator to use val=
ue semantics. In exchange, a lot of decisions would simply be made for us: =
they would just be objects, with all the same behaviour around inheritance,=
 serialization, and so on.

Right, this would either require some other marker that switches to
this mode of comparison, or operator overloading.

Ilija