Hey Dmitry,
Please remember to bottom post!
On Mon, Jul 14, 2025, at 11:16, Dmitry Derepko wrote:
> Hi, Rob!
>
> I'm just wondering, why the implementation differs from a regular class?
>
> Record makes a "class" immutable and unique, using field value comparison
> instead of object refs. It has a custom `with` method which is similar to the
> new `clone` operator accepted recently. I'd suggest not introducing a new
> keyword "record" and new syntax to create records, but use regular `class`
> and `new Class`. Class should have a modifier "data" like readonly, so it
> should be:
>
> data class Record {
> public function __construct(public $a){} // $a is mutable, because why
> not?
> }
>
> Data class will compare with others using field value comparison. Moreover,
> if you want to make it readonly, use the existing keyword to achieve this:
>
> readonly data class Record {
> public function __construct(public $a){} // $a is immutable, because of
> "readonly" class modifier
> }
Data classes are basically structs (as we collectively discovered last December
when I tried implementing exactly that). Records are implemented completely
differently than structs, even though they seem very similar. This is largely
why they’re completely different keywords. Further, records were meant to be
nested inside other classes, and I did try to actually pull that off with
regular classes — and it was declined. This negates the short-syntax and nested
aspect of records.
>
> 1. So record Record {} becomes readonly data class Record {}
A record is not a class just like an enum is not a class. :) Though, it is
class-like semantics.
> 2. We introduce data classes, which are similar to records and are mutable by
> default
You’re referring to structs, not records.
> 3. No new constructions to create the new type of classes, no adjustments for
> autoloading and other things internally
Records aren’t created (aka, "new'd"); that’s an intentional design choice.
Whether or not it is a good one is still up for debate.
> 4. Eliminate with method, replace `with` method with the new `clone`
The new clone is not compatible with records or any other type defined via a
constructor (including regular classes). This was a deliberate choice of that
implementation. Here's some examples run on that branch:
<?php
final readonly class Response {
public function __construct(
public int $statusCode,
public string $reasonPhrase,
// ...
) {
if($this->statusCode >= 600) {
throw new LogicException();
}
}
}
$test = new Response(404, "Not Found");
var_dump($test);
$test = clone($test, ['statusCode' => 900]);
var_dump($test);
--- output ---
PHP Fatal error: Uncaught Error: Cannot modify protected(set) readonly
property Response::$statusCode from global scope in
/home/withinboredom/code/php-src/test.php:28
Stack trace:
#0 /home/withinboredom/code/php-src/test.php(28): clone()
#1 {main}
thrown in /home/withinboredom/code/php-src/test.php on line 28
Fatal error: Uncaught Error: Cannot modify protected(set) readonly property
Response::$statusCode from global scope in
/home/withinboredom/code/php-src/test.php:28
Stack trace:
#0 /home/withinboredom/code/php-src/test.php(28): clone()
#1 {main}
thrown in /home/withinboredom/code/php-src/test.php on line 28
Then removing the readonly distinction:
object(Response)#1 (2) {
["statusCode"]=>
int(404)
["reasonPhrase"]=>
string(9) "Not Found"
}
object(Response)#2 (2) {
["statusCode"]=>
int(900)
["reasonPhrase"]=>
string(9) "Not Found"
}
---
As you can see, it doesn't work for readonly classes and allows invalid mutable
objects to be created, requiring devs to rethink how validation will be
structured as this will make any constructor validations entirely bypassable in
PHP 8.5+. Previously, you needed to use reflection to do this, but now it is
going to be incredibly easy and a footgun. I think this will be another weird
quirk of PHP from now on and it is by design.
> 5. Inline constructor isn’t necessary and could be proposed separately. I’ve
> thought recently about this feature
I will probably remove this, to be honest. It was for nesting records inside
classes or other records, but this feature was declined, so there isn't really
a need for it.
>
> WDYT?
>
>
> (sorry for the duplicate in private mailbox)
>
> ----------
>
> Best regards,
> Dmitrii Derepko.
> @xepozz
Data classes are much more similar to structs than to records -- and are even
implemented completely differently. Records are effectively just well-defined
arrays with behaviour attached. They're not classes, but offer similar
semantics.
— Rob
