Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122951
Feedback-ID: id5114917:Fastmail
Content-Type: multipart/alternative;
 boundary="------------tyC3wj0WCwBoWAy7x0E06jZh"
Message-ID: <9f66fd2b-d93e-42d1-906a-ca83cc51b08e@rwec.co.uk>
Date: Thu, 4 Apr 2024 23:28:29 +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>
 <d02a2d11-cbe3-4fef-9181-2fbac8988f34@rwec.co.uk>
 <CAPyj-LA49UoAqtSekwxuMwHUv0FyAUdUtQ_m12dQTSDP-VQhLA@mail.gmail.com>
Content-Language: en-GB
In-Reply-To: <CAPyj-LA49UoAqtSekwxuMwHUv0FyAUdUtQ_m12dQTSDP-VQhLA@mail.gmail.com>
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

This is a multi-part message in MIME format.
--------------tyC3wj0WCwBoWAy7x0E06jZh
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 03/04/2024 00:01, Ilija Tovilo wrote:
> Data classes are classes with a single additional  > zend_class_entry.ce_flags flag. So unless customized, they behave as 
 > classes. This way, we have the option to tweak any behavior we would 
 > like, but we don't need to. > > Of course, this will still require an 
analysis of what behavior we > might want to tweak.

Regardless of the implementation, there are a lot of interactions we 
will want to consider; and we will have to keep considering new ones as 
we add to the language. For instance, the Property Hooks RFC would 
probably have needed a section on "Interaction with Data Classes".

On the other hand, maybe having two types of objects to consider each 
time is better than having to consider combinations of lots of small 
features.


On a practical note, a few things I've already thought of to consider:

- Can a data class have readonly properties (or be marked "readonly data 
class")? If so, how will they behave?
- Can you explicitly use the "clone" keyword with an instance of a data 
class? Does it make any difference?
- Tied into that: can you implement __clone(), and when will it be called?
- If you implement __set(), will copy-on-write be triggered before it's 
called?
- Can you implement __destruct()? Will it ever be called?



> Consider this example, which would  > work with the current approach: > > $shapes[0]->position->zero!();

I find this concise example confusing, and I think there's a few things 
to unpack here...


Firstly, there's putting a data object in an array:

$numbers = [ new Number(42) ];
$cow = $numbers;
$cow[0]->increment!();
assert($numbers !== $cow);

This is fairly clearly equivalent to this:

$numbers = [ 42 ];
$cow = $numbers;
$cow[0]++;
assert($numbers !== $cow);

CoW is triggered on the array for both, because ++ and ->increment!() 
are both clearly modifications.


Second, there's putting a data object into another data object:

$shape = new Shape(new Position(42,42));
$cow = $shape;
$cow->position->zero!();
assert($shape !== $cow);

This is slightly less obvious, because it presumably depends on the 
definition of Shape. Assuming Position is a data class:

- If Shape is a normal class, changing the value of $cow->position just 
happens in place, and the assertion fails

- If Shape is a readonly class (or position is a readonly property on a 
normal class), changing the value of $cow->position shouldn't be 
allowed, so this will presumably give an error

- If Shape is a data class, changing the value of $shape->position 
implies a "mutation" of $shape itself, so we get a separation before 
anything is modified, and the assertion passes

Unlike in the array case, this behaviour can't be resolved until you 
know the run-time type of $shape.


Now, back to your example:

$shapes = [ new Shape(new Position(42,42)) ];
$cow = $shapes;
$shapes[0]->position->zero!(); assert($cow !== $shapes);

This combines the two, meaning that now we can't know whether to 
separate the array until we know (at run-time) whether Shape is a normal 
class or a data class.

But once that is known, the whole of "->position->zero!()" is a 
modification to $shapes[0], so we need to separate $shapes.


> Without such a class-wide marker, you'll need to remember to add the
> special syntax exactly where applicable.
>
> $shapes![0]!->position!->zero();


The array access doesn't need any special marker, because there's no 
ambiguity. The ambiguous call is the reference to ->position: in your 
current proposal, this represents a modification *if Shape is a data 
class, and is itself being modified*. My suggestion (or really, thought 
experiment) was that it would represent a modification *if it has a ! in 
the call*.

So if Shape is a readonly class:

$shapes[0]->position->!zero();
// Error: attempting to modify readonly property Shape::$position

$shapes[0]->!position->!zero();
// OK; an optimised version of:
$shapes[0] = clone $shapes[0] with [
     'position' =>  (clone $shapes[0]->position with ['x'=>0,'y'=>0])
];

If ->! is only allowed if the RHS is either a readonly property or a 
mutating method, then this can be reasoned about statically: it will 
either error, or cause a CoW separation of $shapes. It also allows 
classes to mix aspects of "data class" and "normal class" behaviour, 
which might or might not be a good idea.


This is mostly just a thought experiment, but I am a bit concerned that 
code like this is going to be confusingly ambiguous:

$item->shape->position->zero!();

What is going to be CoW cloned, and what is going to be modified in 
place? I can't actually know without knowing the definition behind both 
$item and $item->shape. It might even vary depending on input.


Regards,

-- 
Rowan Tommins
[IMSoP]

--------------tyC3wj0WCwBoWAy7x0E06jZh
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    On 03/04/2024 00:01, Ilija Tovilo wrote:<br>
    <span style="white-space: pre-wrap; display: block; width: 98vw;">&gt; Data classes are classes with a single additional
&gt; zend_class_entry.ce_flags flag. So unless customized, they behave as
&gt; classes. This way, we have the option to tweak any behavior we would
&gt; like, but we don't need to.
&gt;
&gt; Of course, this will still require an analysis of what behavior we
&gt; might want to tweak.
</span><br>
    <p>Regardless of the implementation, there are a lot of interactions
      we will want to consider; and we will have to keep considering new
      ones as we add to the language. For instance, the Property Hooks
      RFC would probably have needed a section on "Interaction with Data
      Classes".</p>
    On the other hand, maybe having two types of objects to consider
    each time is better than having to consider combinations of lots of
    small features.<br>
    <p><br>
    </p>
    On a practical note, a few things I've already thought of to
    consider:<br>
    <br>
    - Can a data class have readonly properties (or be marked "readonly
    data class")? If so, how will they behave?<br>
    - Can you explicitly use the "clone" keyword with an instance of a
    data class? Does it make any difference?<br>
    - Tied into that: can you implement __clone(), and when will it be
    called?<br>
    - If you implement __set(), will copy-on-write be triggered before
    it's called?<br>
    - Can you implement __destruct()? Will it ever be called?<br>
    <br>
    <p><br>
    </p>
    <p><br>
    </p>
    <span style="white-space: pre-wrap; display: block; width: 98vw;">&gt; Consider this example, which would
&gt; work with the current approach:
&gt;
&gt; $shapes[0]-&gt;position-&gt;zero!();
</span>
    <p>I find this concise example confusing, and I think there's a few
      things to unpack here...</p>
    <p><br>
    </p>
    <p>Firstly, there's putting a data object in an array:</p>
    <p>$numbers = [ new Number(42) ];<br>
      $cow = $numbers;<br>
      $cow[0]-&gt;increment!();<br>
      assert($numbers !== $cow);<br>
    </p>
    <p>This is fairly clearly equivalent to this:<br>
    </p>
    <p>$numbers = [ 42 ];<br>
      $cow = $numbers;<br>
      $cow[0]++;<br>
      assert($numbers !== $cow);</p>
    <p>CoW is triggered on the array for both, because ++ and
      -&gt;increment!() are both clearly modifications.</p>
    <p><br>
    </p>
    <p>Second, there's putting a data object into another data object:<br>
    </p>
    <p>$shape = new Shape(new Position(42,42));<br>
      $cow = $shape;<br>
      $cow-&gt;position-&gt;zero!();<br>
      assert($shape !== $cow);<br>
    </p>
    <p>This is slightly less obvious, because it presumably depends on
      the definition of Shape. Assuming Position is a data class:<br>
    </p>
    <p>- If Shape is a normal class, changing the value of
      $cow-&gt;position just happens in place, and the assertion fails</p>
    <p>- If Shape is a readonly class (or position is a readonly
      property on a normal class), changing the value of
      $cow-&gt;position shouldn't be allowed, so this will presumably
      give an error</p>
    <p>- If Shape is a data class, changing the value of
      $shape-&gt;position implies a "mutation" of $shape itself, so we
      get a separation before anything is modified, and the assertion
      passes</p>
    <p>Unlike in the array case, this behaviour can't be resolved until
      you know the run-time type of $shape.<br>
    </p>
    <p><br>
    </p>
    <p>Now, back to your example:</p>
    <p>$shapes = [ new Shape(new Position(42,42)) ];<br>
      $cow = $shapes;<br>
      <span style="white-space: pre-wrap; display: block; width: 98vw;">$shapes[0]-&gt;position-&gt;zero!();
assert($cow !== $shapes);
</span></p>
    <p><span style="white-space: pre-wrap; display: block; width: 98vw;">This combines the two, meaning that now we can't know whether to separate the array until we know (at run-time) whether Shape is a normal class or a data class.</span></p>
    <p><span style="white-space: pre-wrap; display: block; width: 98vw;">But once that is known, the whole of "-&gt;position-&gt;zero!()" is a modification to $shapes[0], so we need to separate $shapes.
</span></p>
    <p><br>
    </p>
    <blockquote type="cite">
      <pre class="moz-quote-pre" wrap="">Without such a class-wide marker, you'll need to remember to add the
special syntax exactly where applicable.

$shapes![0]!-&gt;position!-&gt;zero();</pre>
    </blockquote>
    <p><br>
    </p>
    <p>The array access doesn't need any special marker, because there's
      no ambiguity. The ambiguous call is the reference to
      -&gt;position: in your current proposal, this represents a
      modification *if Shape is a data class, and is itself being
      modified*. My suggestion (or really, thought experiment) was that
      it would represent a modification *if it has a ! in the call*.</p>
    <p>So if Shape is a readonly class:<br>
    </p>
    <p>$shapes[0]-&gt;position-&gt;!zero();<br>
      // Error: attempting to modify readonly property Shape::$position</p>
    <p>$shapes[0]-&gt;!position-&gt;!zero();<br>
      // OK; an optimised version of:<br>
      $shapes[0] = clone $shapes[0] with [<br>
          'position' =&gt;  (clone $shapes[0]-&gt;position with
      ['x'=&gt;0,'y'=&gt;0])<br>
      ];</p>
    <p>If -&gt;! is only allowed if the RHS is either a readonly
      property or a mutating method, then this can be reasoned about
      statically: it will either error, or cause a CoW separation of
      $shapes. It also allows classes to mix aspects of "data class" and
      "normal class" behaviour, which might or might not be a good idea.<br>
    </p>
    <p><br>
    </p>
    <p>This is mostly just a thought experiment, but I am a bit
      concerned that code like this is going to be confusingly
      ambiguous:</p>
    <p>$item-&gt;shape-&gt;position-&gt;zero!();</p>
    <p>What is going to be CoW cloned, and what is going to be modified
      in place? I can't actually know without knowing the definition
      behind both $item and $item-&gt;shape. It might even vary
      depending on input.<br>
    </p>
    <p><br>
    </p>
    <p>Regards,<br>
    </p>
    <pre class="moz-signature" cols="72">-- 
Rowan Tommins
[IMSoP]</pre>
  </body>
</html>

--------------tyC3wj0WCwBoWAy7x0E06jZh--