On Sat, Nov 23, 2024, at 7:11 AM, Rob Landers wrote:
> Hello internals,
>
> Born from the Records RFC (https://wiki.php.net/rfc/records)
> discussion, I would like to introduce to you a competing RFC: Data
> Classes (https://wiki.php.net/rfc/dataclass).
>
> This adds a new class modifier: data. This modifier drastically changes
> how classes work, making them comparable by value instead of reference,
> and any mutations behave more like arrays than objects (by vale). If
> desired, it can be combined with other modifiers, such as readonly, to
> enforce immutability.
>
> I've been playing with this feature for a few days now, and it is
> surprisingly intuitive to use. There is a (mostly) working
> implementation available on GitHub
> (https://github.com/php/php-src/pull/16904) if you want to have a go at
> it.
>
> Example:
>
> data class UserId { public function __construct(public int $id) {} }
>
> $user = new UserId(12);
> // later
> $admin = new UserId(12);
> if ($admin === $user) { // do something } // true
>
> Data classes are true value objects, with full copy-on-write optimizations:
>
> data class Point {
> public function __construct(public int $x, public int $y) {}
> public function add(Point $other): Point {
> // illustrating value semantics, no copy yet
> $previous = $this;
> // a copy happens on the next line
> $this->x = $this->x + $other->x;
> $this->y = $this->y + $other->y;
> assert($this !== $previous); // passes
> return $this;
> }
> }
>
> I think this would be an amazing addition to PHP.
>
> Sincerely,
>
> — Rob
Oh boy. Again, I think there's too much going on here, but I think that's
because different people are operating under a different definition of what
"value semantics" means. Let me try to break down what I think are the
constituent parts.
1. Pass-by-value. This is what arrays, ints, strings, etc. do. When you pass
a value to a function, what you get is logically a new value. It may be equal
to the old one, it may be the same memory location as the old one, but that's
hidden from you. Logically, it's a new value. (And if there's a shared memory
location, CoW hides that from you, too.) The intent here is to avoid "spooky
action at a distance" (SAAAD) (that is, changing a value inside a function is
guaranteed to not have any effect on the function that called it).
2. Logical equality. This only applies to compound values (arrays and
objects), but would imply checking equality by recursively checking equality on
sub-elements. (Properties in the case of objects, keys in the case of arrays.)
3. Physical equality. This is what === does, and checks that two variables
refer to the same memory location. Physical equality implies logical equality,
but not vice versa.
4. Immutability. A given variable's value cannot change.
5. Product types. A type that is based on two or more other types. (Eg, Point
is a product of int and int.)
These are all circling around the same problem space, but are all different
things. For instance, rigidly immutable values make pass-by-value irrelevant,
while pass-by-value avoids SAAD without needing immutability.
I think that's the key place where Rob's approach and Ilija's approach differ.
Rob's approach (records and dataclass) are trying to solve SAAAD through
immutability, one way or another. Ilija's approach is trying to solve SAAAD
through pass-by-value semantics.
By-value semantics would be really easy to implement by just auto-cloning an
object at a function boundary. However, that's also very wasteful, as the
object probably won't be modified, making the clone just a memory hog. The
issue is that detecting a modification on nested objects is not particularly
easy, which is how Ilija ended up with an explicit syntax to mark such
modification. (I personally dislike it, from a DX perspective, but I don't
have any suggestions on how to avoid it. If someone else does, please speak
up.)
Immutability semantics, as we've seen, seem easy but are actually quite
logically complex once you get past the bare minimum. (The bare minimum is
already provided by readonly classes. Problem solved.)
So I'm not sure we're all talking about solving the same problem, or solving it
in the same way.
Moreover, I don't think we all agree on the use cases we're solving. Let me
offer a few examples.
1. Fancy typed values
readonly class UserID {
public function __construct(public int $id) {}
}
This is already mostly supported, as above, just a bit verbose. In this case,
it makes sense that two equivalent objects are ==, and if we can make them ===
then that's a nice memory optimization, but not a requirement. In this case,
we're really just providing additional typing, and the immutability is trivial
(and already supported).
2. Product types (part 1)
class Point {
public function __construct(public int $x, public int $y) {}
}
Now here's the interesting part. Should Point be immutable? Should
modifications to Point inside a function affect values outside the function?
MAYBE! It depends on the context. In most cases, probably not. However,
consider a "registration/collection" use case of an event dispatcher:
class RegisterPluginsEvent {
public function __construct(public array $pluginsToRegister) {}
}
This is a "data" class in that it is carrying data, and is not a service.
However, we very clearly DO want SAAAD in this case. That's the whole reason
it exists. Currently this case is solved by conventional classes, so I don't
think there's anything to do here.
3. Product types (part 2)
Where it gets interesting is when you do need to modify an object, and
propagate those changes, but NOT propagate the ability to change it. Consider:
class Circle {
public function __construct(Point $center, int $radius) {}
}
$c = new Circle(new Point(1, 2), 5);
if ($some_user_data) {
$c->center->x = 10;
}
draw($c);
Here, *we do want the ability to modify $c after construction*. However, we do
NOT want to allow draw() to modify our $c. This case is currently unsolved in
PHP.
As above, there's two approaches to solving it: Making $c immutable generally,
or making a copy (immediately or delayed) when passing to draw(). Making $c
immutable generally would, in this case, be bad, because we do want the ability
to modify $c before passing it. It's just much more convenient than needing to
compute everything ahead of time and pass it to the constructor like it's just
a function.
4. Aggregate types
One of the main places that Ilija and I have discussed his structs proposal is
collections[1]. In many languages, collections have both an in-place modifier
and a clone-along-the-way modifier. For instance, sort() and sorted(),
reverse() and reversed(), etc. (Details vary a little by language.) Some
languages also have both mutable and immutable versions of each collection type
(Seq, Set, Map), with the in-place methods only available on the mutable
variant. There's also then methods to convert a mutable collection into an
immutable one and vice versa, which (I believe) implies making a copy. Kotlin
does both of the above, and is the model that I have been planning to pursue in
PHP, eventually.
Ilija has argued that if we can flag collection classes as pass-by-value, then
we don't need the immutable versions at all. The only reason for the immutable
versions to exist is to prevent SAAAD. If that's already prevented by the
passing semantics, then we don't need an explicitly immutable collection.
So that would mean:
$c = new List();
$c->add(1); // in place mutation.
$c->add(3); // in place mutation.
$c->add(2); // in place mutation.
function doStuff(List $l) {
$l->sort(); // in-place mutation of a value-passed value.
// do stuff with l.
}
doStuff($c);
var_dump($c); // Still ordered 1, 3, 2
So a sorted() method or an ImmutableList class wouldn't be necessary. (I can
see a use for sorted() anyway, to make it chainable, just like another recent
RFC proposed for the existing sort() function. That's related but a separate
question.)
This approach would not be possible if data/record/struct/whatever classes have
*any* built-in immutability to them. They just become super cumbersome to work
with. One way or another, you end up back at the withX() methods that we
already have and use.
$c = new List();
$c = $c->add(1);
$c = $c->add(3);
$c = $c->add(2);
// ...
Eew. I can do that already today, and I don't want to.
Here's the important observation: Speaking as the leading functional
programming in PHP fanboy, I don't really see much value at all to
intra-function immutability. It's just... not useful in PHP. Immutability at
function boundaries, that's super useful. But solving the problem at the
object-immutability level is the wrong place in PHP. (It is arguably the right
place in Haskell or ML, but PHP is not Haskell or ML.)
So IMO, the focus should be on just the function boundary semantics. The main
issue is how to make that work without wonky new syntax. Again, I don't have a
good answer, but would kindly request one. :-)
Finally, there's the question of equality. Be aware, PHP *already does value
equality for objects*:
https://3v4l.org/67ho1
The issue isn't that it's not there, it's that it cannot be controlled. I am
not convinced that overriding === to mean logical equality rather than physical
equality, but only for data objects, is wise. And we already have == handled.
(I use that fact in my PHPUnit tests all the time.) What is missing is the
ability to control how that == comparison is made.
class Rect {
private int $area;
public function __construct(public readonly int $h, public readonly int $w) {}
public function area(): int {
$this->area ??= $this->h * $this->w;
}
}
$r1 = new Rect(4, 5);
$r2 = new Rect(4, 5);
print $r1->area;
var_dump($r1 == $r2); // What happens here?
Presumably, we'd want those to be equal without having to compute $area on $r2.
Right now, that's impossible, and those objects would not be equal. Fixing
that has... nothing to do with value semantics at all. It has to do with
operator overloading, and I'm already on record that I am very in favor of
addressing that.
I hope that gives a better lay of the land for everyone in this thread.
--Larry Garfield
[1]
https://thephp.foundation/blog/2024/08/19/state-of-generics-and-collections/#collections
