Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122898
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-333-gbfea15422e-fm-20240327.001-gbfea1542
Precedence: bulk
MIME-Version: 1.0
Message-ID: <c7640414-8b19-40e0-bc08-d128576d88d7@app.fastmail.com>
In-Reply-To: 
 <CAPyj-LBS5iUEX_Y9gqGL_vsFjTgZCsDT3YUGQgZw43oFVE2XiA@mail.gmail.com>
References: 
 <CAPyj-LA7kJLdz3Pzbxr6x-7v2YV8n06pwxs6QoVe3CGgx-_GGA@mail.gmail.com>
 <1a4a44c5-d4f5-40ca-b3dc-13d64c2b4425@app.fastmail.com>
 <CAPyj-LBS5iUEX_Y9gqGL_vsFjTgZCsDT3YUGQgZw43oFVE2XiA@mail.gmail.com>
Date: Tue, 02 Apr 2024 22:02:19 +0000
To: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC][Concept] Data classes (a.k.a. structs)
Content-Type: text/plain
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, Apr 2, 2024, at 6:04 PM, Ilija Tovilo wrote:

>> 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).
>
> One issue that just came to mind is object identity. For example:
>
> class Person {
>     public function __construct(
>         public string $firstname,
>         public string $lastname,
>     ) {}
> }
>
> class Manager extends Person {
>     public function bossAround() {}
> }
>
> $person = new Person('Boss', 'Man');
> $manager = new Manager('Boss', 'Man');
> var_dump($person === $manager); // ???
>
> Equality for data objects is based on data, rather than the object
> handle. How does this interact with inheritance? Technically, Person
> and Manager represent the same data. Manager contains additional
> behavior, but does that change identity?
>
> I'm not sure what the answer is. That's just the first thing that came
> to mind. I'm confident we'll discover more such edge cases. Of course,
> I can invest the time to find the questions before deciding to
> disallow inheritance.

As Bruce already demonstrated, equality should include type, not just properties.  Even without inheritance that is necessary.

There may be good reason to omit inheritance, as we did on enums, but that shouldn't be the starting point.  (I'd have to research and see what other languages do. I think it's a mixed bag.)  We should try to ferret out those edge cases and see if there's reasonable solutions to them.

>> > * 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).)
>
> I think you misunderstood. The intention is to mark both call-site and
> declaration. Call-site is marked with ->method!(), while declaration
> is marked with "public mutating function". Call-site is required to
> avoid the engine complexity, as previously mentioned. But
> declaration-site is required so that the user (and IDEs) even know
> that you need to use the special syntax at the call-site.

Ah, OK.  That's... unfortunate, but I defer to you on the implementation complexity.

>> 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.
>
> I'm just skeptical whether the default __toString() is ever useful. I
> can see an argument for it for quick debugging in languages that don't
> provide something like var_dump(). In PHP this seems much less useful.
> It's impossible to provide a default implementation that works
> everywhere (or pretty much anywhere, even).
>
> Equality is already included. Hashing should be added separately, and
> probably not just to data classes.

The equivalent of Python's __repr__ (which it auto-generates) would be __debugInfo().  Arguably its current output is what the default would likely be anyway, though.  I believe the typical auto-toString output is the same data, but presented in a more human-friendly way.  (So yes, mainly useful for debugging.)

Equality, well, we've already debated whether or not we should make that a general feature. :-)  Of note, though, in languages with equals(), it's also user-overridable.

>> > * 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.

I believe this is where we would want/need a __hash() method or similar; Derick and I encountered that while researching collections in other languages.  Leaving it out for now is fine, but it would be important for any future list-of functionality.

>> 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. :-)
>
> Disallowing ordinary by-ref objects is not trivial without additional
> performance penalties, and I don't see a good reason for it. Can you
> provide an example on when that would be problematic?
>
> Ilija

There's two aspects to it, that I see.

data class A {
  public function __construct(public string $name) {}
}

data class B {
  public function __construct(
    public A $a,
    public PDO $conn,
  ) {}
}

$b = new B(new A(), $pdoConnection);

function stuff(B $b2) {
  $b2->a->name = 'Larry';
  // This triggers a CoW on $b2, separating it from $b, and also creating a new instance of A.  What about $conn?
  // Does it get cloned?  That would be bad.  Does it not get cloned?  That seems weird that it's still the same on
  // a data object.

  $b2->conn->beginTransaction();
  // This I would say is technically a modification, since the state of the connection is changing.  But then 
  // should this trigger $b2 cloning from $b1?  Neither answer is obvious to me.
}

In a sense, it's similar to the "PSR-7 is immutable, asterisk, streams" issue that has often been pointed out.  "Data objects are safe to pass around and will self-clone when needed, asterisk, unless there's a normal object in it and then it's non-obvious" doesn't sound like a good mental model to give people.

Or consider DateTime.  It's mutable.  Should mutating it clone an object that has a DateTime property?  I can realistically argue both ways, and I'm not convinced either is right; just that neither is intuitive.

"Data classes all the way down" resolves this problem.

The caveat would be that a genuinely immutable object would (probably?) be safe (DateTimeImmutable, or a readonly class), so maybe we can make readonly classes an exception?  Ah, no, we cannot, because despite what PHPStan insists, there's no reason that the single write to a readonly property must happen at construction.  It can easily happen as a side effect of another method (eg, a cache value), meaning readonly objects are not truly immutable.  In fact, readonly objects can have non-readonly objects on their properties, too.  So I don't think that's safe, either.

The other aspect is, eg, serialization.  People will come to expect (reasonably) that a data class will have certain properties (in the abstract sense, not lexical sense).  For instance, most classes are serializable, but a few are not.  (Eg, if they have a reference to PDO or a file handle or something unserializable.)  Data classes seem like they should be safe to serialize always, as they're "just data".  If data classes are limited to primitives and data classes internally, that means we can effectively guarantee that they will be serializable, always.  If one of the properties could be a non-serializable object, that assumption breaks.

There's probably other similar examples besides serialization where "think of this as data" and "think of this as logic" is how you'd want to think, which leads to different assumptions, which we shouldn't stealthily break.

--Larry Garfield