Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122895
Feedback-ID: id5114917:Fastmail
Content-Type: multipart/alternative;
 boundary="------------CA6P0Eq3Ss680KHgjtM0011A"
Message-ID: <d02a2d11-cbe3-4fef-9181-2fbac8988f34@rwec.co.uk>
Date: Tue, 2 Apr 2024 21:10:38 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC][Concept] Data classes (a.k.a. structs)
To: internals@lists.php.net
References: <CAPyj-LA7kJLdz3Pzbxr6x-7v2YV8n06pwxs6QoVe3CGgx-_GGA@mail.gmail.com>
Content-Language: en-GB
In-Reply-To: <CAPyj-LA7kJLdz3Pzbxr6x-7v2YV8n06pwxs6QoVe3CGgx-_GGA@mail.gmail.com>
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

This is a multi-part message in MIME format.
--------------CA6P0Eq3Ss680KHgjtM0011A
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 02/04/2024 01:17, Ilija Tovilo wrote:
> 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]

--------------CA6P0Eq3Ss680KHgjtM0011A
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 02/04/2024 01:17, Ilija Tovilo
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAPyj-LA7kJLdz3Pzbxr6x-7v2YV8n06pwxs6QoVe3CGgx-_GGA@mail.gmail.com">
      <pre>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#).</pre>
    </blockquote>
    <p><br>
    </p>
    <p>Hi Ilija,</p>
    <p>I'm really interested to see how this develops. A couple of
      thoughts that immediately occurred to me...<br>
    </p>
    <p><br>
    </p>
    <p>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:</p>
    <p>$start = new Location('Here');<br>
      $end = $start-&gt;move!('There');</p>
    <p>Expecting it to mean this:<br>
    </p>
    <p>$start = new Location('Here');<br>
      $end = $start;<br>
      $end-&gt;move!('There');</p>
    <p>When it would actually mean this:</p>
    <p>$start = new Location('Here');<br>
      $start-&gt;move!('There');<br>
      $end = $start;</p>
    <p><br>
    </p>
    <p>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.<br>
    </p>
    <p>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 -&gt;! operator:<br>
    </p>
    <p>$foo-&gt;!mutate();<br>
      $foo-&gt;!bar = 42;</p>
    <p>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' =&gt; 42 ]<br>
    </p>
    <p>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.<br>
    </p>
    <p>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.<br>
    </p>
    <p><br>
    </p>
    <p>Regards,<br>
    </p>
    <pre class="moz-signature" cols="72">-- 
Rowan Tommins
[IMSoP]</pre>
  </body>
</html>

--------------CA6P0Eq3Ss680KHgjtM0011A--