Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125976
Precedence: bulk
MIME-Version: 1.0
References: <d603f372-5f58-4308-aba1-151c35f3aa94@app.fastmail.com>
In-Reply-To: <d603f372-5f58-4308-aba1-151c35f3aa94@app.fastmail.com>
Date: Sun, 17 Nov 2024 01:15:47 +0100
Message-ID: <CAPyj-LCtzF6FKwGakaouyueaLRQsu=B4uASFZKEG4x+-a2J2iA@mail.gmail.com>
Subject: Re: [PHP-DEV] RFC: Records
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 Rob


On Sun, Nov 17, 2024 at 12:15=E2=80=AFAM Rob Landers <rob@bottled.codes> wr=
ote:
>
> Hello internals,
>
> I'm ready as I'm going to be to introduce to you: "Records" https://wiki.=
php.net/rfc/records!

Thanks for your proposal. I very much agree that value semantics are a
highly desirable feature. I sent out my concept proposal on how this
may be achieved through structs some months ago. [1] There are some
remaining technical challenges, but the PoC looks promising. [2]

I personally do not think immutable data structures are a good
solution to the problem, and I don't feel like we need another,
slightly shorter way to do the same thing. In my proposal, I mentioned
that there are two primary issues with immutable data structures:

1. They are expensive. Any modification of the class requires a clone
of the object by design, even when the cloned object is immediately
discarded. This is most noticeable for lists and other growable data
types, because they are large and change frequently. An O(n) insertion
becomes infeasible very fast.
2. The clone is explicit, which gets old pretty quickly. Many of PHPs
quality-of-life features like op-assign (e.g. +=3D) become unusable.

Structs would instead be fully-fledged objects that adopt CoW
(copy-on-write) semantics, which is how PHP already implements arrays.
Essentially, objects are automatically cloned when they are changed
_and_ when the object is referenced from multiple places. If the
object is not referenced anywhere else, it may be safely mutated
without a clone, as there is nobody to observe this side-effect. When
a shared object is mutated multiple times (e.g. an append to a list in
a loop), only the first mutation requires a clone. It's also something
you don't need to think about, it just happens.

As mentioned, the main motivation of my proposal is to implement new
dedicated data structures like Vectors, Maps, Sets, etc. in PHP
(userland and extensions) without sacrificing ergonomics or
performance. However, they would also solve the same challenges for
simple data objects. IMO, immutability was never a great solution to
the problem of "spooky action at a distance". Mutability itself is not
a problem, just shared mutability.

Note that this concept is heavily inspired by Swift, Rust and likely
other languages I don't know. Chris Lattner (the original author of
LLVM and Swift) has shared very similar thoughts in an interview
recently. [3]

If the primary motivation of your RFC is to reduce boilerplate, then
it's true that structs would not help much. I do wonder whether 1. we
need even shorter code and 2. if we do, whether it's something that
could be added to classes alike, rather than tying it to records when
it could be more generic instead.

A small note: The $test =3D &Test(); syntax is ambiguous, as it's
already legal. https://3v4l.org/CE5rt

Ilija

[1] https://externals.io/message/122845
[2] https://github.com/php/php-src/pull/13800
[3] https://youtu.be/JRcXUuQYR90?si=3Dp51_x3wkfeeeGfq-&t=3D3319