[RFC][Concept] Data classes (a.k.a. structs) View as Markdown

Hi everyone!

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#).

In a nutshell, data classes are classes with value semantics.
Instances of data classes are implicitly copied when assigned to a
variable, or when passed to a function. When the new instance is
modified, the original instance remains untouched. This might sound
familiar: It's exactly how arrays work in PHP.

$a = [1, 2, 3];
$b = $a;
$b[] = 4;
var_dump($a); // [1, 2, 3]
var_dump($b); // [1, 2, 3, 4]

You may think that copying the array on each assignment is expensive,
and you would be right. PHP uses a trick called copy-on-write, or CoW
for short. $a and $b actually share the same array until $b[] = 4; modifies it. It's only at this point that the array is copied and
replaced in $b, so that the modification doesn't affect $a. As
long as a variable is the sole owner of a value, or none of the
variables modify the value, no copy is needed. Data classes use the
same mechanism.

But why value semantics in the first place? There are two major flaws
with by-reference semantics for data structures:

1. It's very easy to forget cloning data that is referenced somewhere
   else before modifying it. This will lead to "spooky actions at a
   distance". Having recently used JavaScript (where all data structures
   have by-reference semantics) for an educational IR optimizer,
   accidental mutations of shared arrays/maps/sets were my primary source
   of bugs.
2. Defensive cloning (to avoid issue 1) will lead to useless work when
   the value is not referenced anywhere else.

PHP offers readonly properties and classes to address issue 1.
However, they further promote issue 2 by making it impossible to
modify values without cloning them first, even if we know they are not
referenced anywhere else. Some APIs further exacerbate the issue by
requiring multiple copies for multiple modifications (e.g.
$response->withStatus(200)->withHeader('X-foo', 'foo');).

As you may have noticed, arrays already solve both of these issues
through CoW. Data classes allow implementing arbitrary data structures
with the same value semantics in core, extensions or userland. For
example, a Vector data class may look something like the following:

data class Vector {
    private $values;

    public function __construct(...$values) {
        $this->values = $values;
    }

    public mutating function append($value) {
        $this->values[] = $value;
    }
}

$a = new Vector(1, 2, 3);
$b = $a;
$b->append!(4);
var_dump($a); // Vector(1, 2, 3)
var_dump($b); // Vector(1, 2, 3, 4)

An internal Vector implementation might offer a faster and stricter
alternative to arrays (e.g. Vector from php-ds).

Exciting times to be a PHP Developer!

Some other things to note about data classes:

• Data classes are ordinary classes, and as such may implement
  interfaces, methods and more. I have not decided whether they should
  support inheritance.

I'd argue in favor of not including inheritance in the first version.
Taking inheritance out is an impossible BC Break. Not introducing it in the
first stable release gives users a chance to evaluate whether it's
something we will drastically miss.

• Mutating method calls on data classes use a slightly different
  syntax: $vector->append!(42). All methods mutating $this must be
  marked as mutating. The reason for this is twofold: 1. It signals to
  the caller that the value is modified. 2. It allows $vector to be
  cloned before knowing whether the method append is modifying, which
  hugely reduces implementation complexity in the engine.

I'm not sure if I understood this one. Do you mean that the ! modifier
here (at call-site) is helping the engine clone the variable before even
diving into whether append() has been tagged as mutating? From outside it
looks odd that a clone would happen ahead-of-time while talking about
copy-on-write. Would this syntax break for non-mutating methods?

• Data classes customize identity (===) comparison, in the same way
  arrays do. Two data objects are identical if all their properties are
  identical (including order for dynamic properties).
• Sharing data classes by-reference is possible using references, as
  you would for arrays.
• We may decide to auto-implement __toString for data classes,
  amongst other things. I am still undecided whether this is useful for
  PHP.
• Data classes protect from interior mutability. More concretely,
  mutating nested data objects stored in a readonly property is not
  legal, whereas it would be if they were ordinary objects.
• In the future, it should be possible to allow using data classes in
  SplObjectStorage. However, because hashing is complex, this will be
  postponed to a separate RFC.

One known gotcha is that we cannot trivially enforce placement of
modfying on methods without a performance hit. It is the
responsibility of the user to correctly mark such methods.

Here's a fully functional PoC, excluding JIT:
https://github.com/php/php-src/pull/13800

Let me know what you think. I will start working on an RFC draft once
work on property hooks concludes.

Ilija

Looking forward to this!!!

--
Marco Deleu

Hi everyone!

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#).

data class Vector {
    private $values;

    public function __construct(...$values) {
        $this->values = $values;
    }

    public mutating function append($value) {
        $this->values[] = $value;
    }
}

$a = new Vector(1, 2, 3);
$b = $a;
$b->append!(4);
var_dump($a); // Vector(1, 2, 3)
var_dump($b); // Vector(1, 2, 3, 4)

While I like the idea, I would like to suggest something else in
addition or as a separate feature. As an active user of readonly
classes with all promoted properties for data-holding purposes, I
would be happy to see the possibility of cloning them with passing
some properties to modify:

readonly class Data {
function __construct(
public string $foo,
public string $bar,
public string $baz,
) {}
}

$data = new Data(foo: 'A', bar: 'B', baz: 'C');

$data2 = clone $data with (bar: 'X', baz: 'Y');

Under the hood, this "clone" will copy all values of promoted
properties as is but modify some of them to custom values specified by
the user. The implementation of this functionality in the userland
destroys the beauty of readonly classes with promoted properties.
Manual implementation requires a lot of code lines while bringing no
sense to users who read this code. Cloning methods are bigger than the
meaningful part of the class - the constructor with properties
declaration. Because I have to redeclare all the properties in the
method arguments and then initialize each property with a
corresponding value. I love readonly classes with promoted properties
for data-holding purposes and the above feature is the only one I'm
missing to be completely happy.

In my personal experience, I never needed to copy data classes like
arrays, the immutability protects against unwanted changes enough. But
copying references helps to save memory, some datasets I work with can
be very big.

--
Best,
Alex

Hi everyone!

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#).

gets popcorn

In a nutshell, data classes are classes with value semantics.
Instances of data classes are implicitly copied when assigned to a
variable, or when passed to a function. When the new instance is
modified, the original instance remains untouched. This might sound
familiar: It's exactly how arrays work in PHP.

$a = [1, 2, 3];
$b = $a;
$b[] = 4;
var_dump($a); // [1, 2, 3]
var_dump($b); // [1, 2, 3, 4]

You may think that copying the array on each assignment is expensive,
and you would be right. PHP uses a trick called copy-on-write, or CoW
for short. $a and $b actually share the same array until $b[] = 4; modifies it. It's only at this point that the array is copied and
replaced in $b, so that the modification doesn't affect $a. As
long as a variable is the sole owner of a value, or none of the
variables modify the value, no copy is needed. Data classes use the
same mechanism.

But why value semantics in the first place? There are two major flaws
with by-reference semantics for data structures:

1. It's very easy to forget cloning data that is referenced somewhere
   else before modifying it. This will lead to "spooky actions at a
   distance". Having recently used JavaScript (where all data structures
   have by-reference semantics) for an educational IR optimizer,
   accidental mutations of shared arrays/maps/sets were my primary source
   of bugs.
2. Defensive cloning (to avoid issue 1) will lead to useless work when
   the value is not referenced anywhere else.

PHP offers readonly properties and classes to address issue 1.
However, they further promote issue 2 by making it impossible to
modify values without cloning them first, even if we know they are not
referenced anywhere else. Some APIs further exacerbate the issue by
requiring multiple copies for multiple modifications (e.g.
$response->withStatus(200)->withHeader('X-foo', 'foo');).

As you may have noticed, arrays already solve both of these issues
through CoW. Data classes allow implementing arbitrary data structures
with the same value semantics in core, extensions or userland. For
example, a Vector data class may look something like the following:

data class Vector {
    private $values;

    public function __construct(...$values) {
        $this->values = $values;
    }

    public mutating function append($value) {
        $this->values[] = $value;
    }
}

$a = new Vector(1, 2, 3);
$b = $a;
$b->append!(4);
var_dump($a); // Vector(1, 2, 3)
var_dump($b); // Vector(1, 2, 3, 4)

An internal Vector implementation might offer a faster and stricter
alternative to arrays (e.g. Vector from php-ds).

Some other things to note about data classes:

• Data classes are ordinary classes, and as such may implement
  interfaces, methods and more. I have not decided whether they should
  support inheritance.

What would be the reason not to? As you indicated in another reply, the main reason some languages don't is to avoid large stack copies, but PHP doesn't have large stack copies for objects anyway so that's a non-issue.

I've long argued that the fewer differences there are between service classes and data classes, the better, so I'm not sure what advantage this would have other than "ugh, inheritance is such a mess" (which is true, but that ship sailed long ago).

• Mutating method calls on data classes use a slightly different
  syntax: $vector->append!(42). All methods mutating $this must be
  marked as mutating. The reason for this is twofold: 1. It signals to
  the caller that the value is modified. 2. It allows $vector to be
  cloned before knowing whether the method append is modifying, which
  hugely reduces implementation complexity in the engine.

As discussed in R11, it would be very beneficial if this marker could be on the method definition, not the method invocation. You indicated that would be Hard(tm), but I think it's worth some effort to see if it's surmountably hard. (Or at least less hard than just auto-detecting it, which you indicated is Extremely Hard(tm).)

• Data classes customize identity (===) comparison, in the same way
  arrays do. Two data objects are identical if all their properties are
  identical (including order for dynamic properties).

• Sharing data classes by-reference is possible using references, as
  you would for arrays.

• We may decide to auto-implement __toString for data classes,
  amongst other things. I am still undecided whether this is useful for
  PHP.

For reference:

Java record classes auto-generate equals(), toString(), hashCode(), and same-name methods (we don't need that).

Kotlin data classes auto-generate equals(), toString(), hashCode(), same-name methods, and a copy() method that is basically what we've been discussing as clone-with.

C# record classes auto-generate equals() and ToString(), and are immutable. They also support "with expressions" ($foo with { new args }, basically clone-with).

C# record structs auto-generate equals() and ToString(), and are mutable. (Go figure.)

Python data classes are highly configurable, but by default generate toString(), a var-dump-targeted string (repr), a hash function, and some other Python-specific things with no PHP-equivalent. They can also opt-in to generating ordering overrides (op overloads), being readonly (frozen), or being named-args-only.

Swift structs, from what I can find just briefly, don't seem to auto-generate anything. (I could be wrong here.)

(In basically all cases above, providing your own implementation in the data class overrides the default generated one.)

The concept doesn't exist in C/++, Go, or Rust, at least not in a usefully equivalent way. TypeScript doesn't seem to have them from what I can find.

So to the extent there is a consensus, equality, stringifying, and a hashcode (which we don't have yet, but will need in the future for some things I suspect) seem to be the rough expected defaults.

• Data classes protect from interior mutability. More concretely,
  mutating nested data objects stored in a readonly property is not
  legal, whereas it would be if they were ordinary objects.
• In the future, it should be possible to allow using data classes in
  SplObjectStorage. However, because hashing is complex, this will be
  postponed to a separate RFC.

Would data class properties only be allowed to be other data classes, or could they hold a non-data class? My knee jerk response is they should be data classes all the way down; the only counter-argument I can think of it would be how much existing code is out there that is a "data class" in all but name. I still fear someone adding a DB connection object to a data class and everything going to hell, though. :-)

One known gotcha is that we cannot trivially enforce placement of
modfying on methods without a performance hit. It is the
responsibility of the user to correctly mark such methods.

Here's a fully functional PoC, excluding JIT:
https://github.com/php/php-src/pull/13800

Let me know what you think. I will start working on an RFC draft once
work on property hooks concludes.

Ilija

--Larry Garfield

Hi everyone!

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#).

In a nutshell, data classes are classes with value semantics.
Instances of data classes are implicitly copied when assigned to a
variable, or when passed to a function. When the new instance is
modified, the original instance remains untouched. This might sound
familiar: It's exactly how arrays work in PHP.

$a = [1, 2, 3];
$b = $a;
$b[] = 4;
var_dump($a); // [1, 2, 3]
var_dump($b); // [1, 2, 3, 4]

You may think that copying the array on each assignment is expensive,
and you would be right. PHP uses a trick called copy-on-write, or CoW
for short. $a and $b actually share the same array until $b[] = 4; modifies it. It's only at this point that the array is copied and
replaced in $b, so that the modification doesn't affect $a. As
long as a variable is the sole owner of a value, or none of the
variables modify the value, no copy is needed. Data classes use the
same mechanism.

But why value semantics in the first place? There are two major flaws
with by-reference semantics for data structures:

1. It's very easy to forget cloning data that is referenced somewhere
   else before modifying it. This will lead to "spooky actions at a
   distance". Having recently used JavaScript (where all data structures
   have by-reference semantics) for an educational IR optimizer,
   accidental mutations of shared arrays/maps/sets were my primary source
   of bugs.
2. Defensive cloning (to avoid issue 1) will lead to useless work when
   the value is not referenced anywhere else.

PHP offers readonly properties and classes to address issue 1.
However, they further promote issue 2 by making it impossible to
modify values without cloning them first, even if we know they are not
referenced anywhere else. Some APIs further exacerbate the issue by
requiring multiple copies for multiple modifications (e.g.
$response->withStatus(200)->withHeader('X-foo', 'foo');).

As you may have noticed, arrays already solve both of these issues
through CoW. Data classes allow implementing arbitrary data structures
with the same value semantics in core, extensions or userland. For
example, a Vector data class may look something like the following:

data class Vector {
    private $values;

    public function __construct(...$values) {
        $this->values = $values;
    }

    public mutating function append($value) {
        $this->values[] = $value;
    }
}

$a = new Vector(1, 2, 3);
$b = $a;
$b->append!(4);
var_dump($a); // Vector(1, 2, 3)
var_dump($b); // Vector(1, 2, 3, 4)

An internal Vector implementation might offer a faster and stricter
alternative to arrays (e.g. Vector from php-ds).

Some other things to note about data classes:

• Data classes are ordinary classes, and as such may implement
  interfaces, methods and more. I have not decided whether they should
  support inheritance.
• Mutating method calls on data classes use a slightly different
  syntax: $vector->append!(42). All methods mutating $this must be
  marked as mutating. The reason for this is twofold: 1. It signals to
  the caller that the value is modified. 2. It allows $vector to be
  cloned before knowing whether the method append is modifying, which
  hugely reduces implementation complexity in the engine.
• Data classes customize identity (===) comparison, in the same way
  arrays do. Two data objects are identical if all their properties are
  identical (including order for dynamic properties).
• Sharing data classes by-reference is possible using references, as
  you would for arrays.
• We may decide to auto-implement __toString for data classes,
  amongst other things. I am still undecided whether this is useful for
  PHP.
• Data classes protect from interior mutability. More concretely,
  mutating nested data objects stored in a readonly property is not
  legal, whereas it would be if they were ordinary objects.
• In the future, it should be possible to allow using data classes in
  SplObjectStorage. However, because hashing is complex, this will be
  postponed to a separate RFC.

One known gotcha is that we cannot trivially enforce placement of
modfying on methods without a performance hit. It is the
responsibility of the user to correctly mark such methods.

Here's a fully functional PoC, excluding JIT:
https://github.com/php/php-src/pull/13800

Let me know what you think. I will start working on an RFC draft once
work on property hooks concludes.

Ilija

Neat! I've been playing around with "value-like" objects for awhile now:

https://github.com/withinboredom/time

Having inheritance supported would be useful, for example, consider an ID type:

data class Id {
public function __construct(public string $id) {}
}

Maybe you want to extend it to a UserId:

data class UserId extends Id {}

Now you can't accidentally pass a VideoId as a UserId, but underlying
ORMs can still use both as an Id.

Robert Landers
Software Engineer
Utrecht NL

Hi everyone!

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#).

In a nutshell, data classes are classes with value semantics.
Instances of data classes are implicitly copied when assigned to a
variable, or when passed to a function. When the new instance is
modified, the original instance remains untouched. This might sound
familiar: It's exactly how arrays work in PHP.

$a = [1, 2, 3];
$b = $a;
$b[] = 4;
var_dump($a); // [1, 2, 3]
var_dump($b); // [1, 2, 3, 4]

You may think that copying the array on each assignment is expensive,
and you would be right. PHP uses a trick called copy-on-write, or CoW
for short. $a and $b actually share the same array until $b[] = 4; modifies it. It's only at this point that the array is copied and
replaced in $b, so that the modification doesn't affect $a. As
long as a variable is the sole owner of a value, or none of the
variables modify the value, no copy is needed. Data classes use the
same mechanism.

But why value semantics in the first place? There are two major flaws
with by-reference semantics for data structures:

1. It's very easy to forget cloning data that is referenced somewhere
   else before modifying it. This will lead to "spooky actions at a
   distance". Having recently used JavaScript (where all data structures
   have by-reference semantics) for an educational IR optimizer,
   accidental mutations of shared arrays/maps/sets were my primary source
   of bugs.
2. Defensive cloning (to avoid issue 1) will lead to useless work when
   the value is not referenced anywhere else.

PHP offers readonly properties and classes to address issue 1.
However, they further promote issue 2 by making it impossible to
modify values without cloning them first, even if we know they are not
referenced anywhere else. Some APIs further exacerbate the issue by
requiring multiple copies for multiple modifications (e.g.
$response->withStatus(200)->withHeader('X-foo', 'foo');).

As you may have noticed, arrays already solve both of these issues
through CoW. Data classes allow implementing arbitrary data structures
with the same value semantics in core, extensions or userland. For
example, a Vector data class may look something like the following:

data class Vector {
    private $values;

    public function __construct(...$values) {
        $this->values = $values;
    }

    public mutating function append($value) {
        $this->values[] = $value;
    }
}

$a = new Vector(1, 2, 3);
$b = $a;
$b->append!(4);
var_dump($a); // Vector(1, 2, 3)
var_dump($b); // Vector(1, 2, 3, 4)

An internal Vector implementation might offer a faster and stricter
alternative to arrays (e.g. Vector from php-ds).

Some other things to note about data classes:

• Data classes are ordinary classes, and as such may implement
  interfaces, methods and more. I have not decided whether they should
  support inheritance.
• Mutating method calls on data classes use a slightly different
  syntax: $vector->append!(42). All methods mutating $this must be
  marked as mutating. The reason for this is twofold: 1. It signals to
  the caller that the value is modified. 2. It allows $vector to be
  cloned before knowing whether the method append is modifying, which
  hugely reduces implementation complexity in the engine.
• Data classes customize identity (===) comparison, in the same way
  arrays do. Two data objects are identical if all their properties are
  identical (including order for dynamic properties).
• Sharing data classes by-reference is possible using references, as
  you would for arrays.
• We may decide to auto-implement __toString for data classes,
  amongst other things. I am still undecided whether this is useful for
  PHP.
• Data classes protect from interior mutability. More concretely,
  mutating nested data objects stored in a readonly property is not
  legal, whereas it would be if they were ordinary objects.
• In the future, it should be possible to allow using data classes in
  SplObjectStorage. However, because hashing is complex, this will be
  postponed to a separate RFC.

One known gotcha is that we cannot trivially enforce placement of
modfying on methods without a performance hit. It is the
responsibility of the user to correctly mark such methods.

Here's a fully functional PoC, excluding JIT:
https://github.com/php/php-src/pull/13800

Let me know what you think. I will start working on an RFC draft once
work on property hooks concludes.

Ilija

Hi Ilija

Thank you for this proposal, I like the idea of having value semantic objects available.
I pulled your branch and played with it a bit.

As already hinted in the thread, I also think inheritance may be dangerous in a first version.
I want to add to that: if you extend a data-class with a non-data-class, the data-class behaviour gets lost, which is logical in a sense but also surprised me in a way.

Also, FWIW, I'm not sure about the name "data" class, perhaps "value" class or something alike is what people may be more familiar with wrt semantics, although dataclass is also a known term.

I do have a question about iterator behaviour. Consider this code:

data class Test {
        public $a = 1;
        public $b = 2;
}

$test = new Test;
foreach ($test as $k => &$v) {
        if ($k === "b")
                $test->a = $test;
        var_dump($k);
}

This will reset the iterator of the object on separation, so we will get an infinite loop.
Is this intended?
If so, is it because the right hand side is the original object while the left hand side gets the clone?
Is this consistent with how arrays separate?
(Note: I haven't really looked at your code)

Kind regards
Niels

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#).

Hi Ilija,

I'm really interested to see how this develops. A couple of thoughts
that immediately occurred to me...

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 return type slot). Otherwise, someone is bound to write this:

$start = new Location('Here');
$end = $start->move!('There');

Expecting it to mean this:

$start = new Location('Here');
$end = $start;
$end->move!('There');

When it would actually mean this:

$start = new Location('Here');
$start->move!('There');
$end = $start;

I seem to remember when this was discussed before, the argument being
made that separating value objects completely means you have to spend
time deciding how they interact with every feature of the language.

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-site marker slightly to a ->! operator:

$foo->!mutate();
$foo->!bar = 42;

The first would be the same as your current version: it would perform a
CoW reference separation / clone, then call the method, which would
require a "mutating" marker. The second would essentially be an
optimised version of $foo = clone $foo with [ 'bar' => 42 ]

During the method call or write operation, readonly properties would
allow an additional write, as is the case in __clone and the "clone
with" proposal. So a "pure" data object would simply be declared with
the existing "readonly class" syntax.

The main drawback I can see (outside of the implementation, which I
can't comment on) is that we couldn't overload the === operator to use
value 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.

Regards,

--
Rowan Tommins
[IMSoP]