Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125979
Feedback-ID: id5114917:Fastmail
Content-Type: multipart/alternative;
 boundary="------------rQWv1780KumNh803ioZG0gL4"
Message-ID: <9e45ff96-7388-466e-813a-74e0dd2700af@rwec.co.uk>
Date: Sun, 17 Nov 2024 23:13:03 +0000
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] RFC: Records
To: internals@lists.php.net
References: <d603f372-5f58-4308-aba1-151c35f3aa94@app.fastmail.com>
 <68eba37e-1bfe-4509-af41-112bb196415c@app.fastmail.com>
 <ab3e32e0-1e1b-438c-a00b-cfe0cdd0f464@app.fastmail.com>
Content-Language: en-GB
In-Reply-To: <ab3e32e0-1e1b-438c-a00b-cfe0cdd0f464@app.fastmail.com>
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

This is a multi-part message in MIME format.
--------------rQWv1780KumNh803ioZG0gL4
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Rob,

I'm torn on this one. On the one hand, it does look like a nice solution 
for adding custom value objects to the language; on the other hand, it's 
a lot of things that are "just slightly different" for users to get used to.


On 17/11/2024 21:30, Rob Landers wrote:
> One of the main reasons for the alternative creation syntax is because 
> I felt that "new" was misleading at best, and just plain wrong at 
> worst. It is also why I chose "&", to make it clear you are not 
> getting "a new one" but one that "just happens to exist with the 
> values you asked for." I'd be open to a different keyword or something 
> else entirely. It's just that "new" is the wrong one for records.


I'm not convinced by this, because I'm not convinced the "mental model" 
in the RFC is the one that most developers need to care about. I think a 
much simpler mental model (for someone who understands the rest of PHP) is:

- records are copy-on-write (like arrays, not like objects)
- the === operator returns true for two records with the same value 
(again like arrays, not like objects)
- the implementation optimises two records with the same values to share 
memory


The third point is useful to know if you're creating a lot of them, but 
probably irrelevant most of the time.

We also might not want to make it a hard guarantee, because there may be 
cases where a different trade-off is more efficient. For instance, maybe 
we will optimise $foo->with(a: 1)->with(b: 2)->with(c: 3) to overwrite 
values in-place, at the cost of an extra condition in the `===` 
implementation.

That would be similar to some of the changes to zvals in PHP 7; for 
instance, "$foo=42; $bar=$foo;" will copy the value 42 to a new piece of 
memory, not increase a zval reference count as PHP 5 would have done.


That leaves the mental model as mostly "records are a bit like arrays". 
Now, it's true that we don't write "new array(1,2,3)"; but I have heard 
people calling the "array()" syntax "the array constructor", and the 
manual describes it as "creating an array". Similarly, you use 
"constructor" and "construction" throughout the RFC.

All of that makes it feel perfectly natural for me to have "new Point(1, 
5)" mean "create a Point record; feel free to save memory by reusing one 
with the same values".


> A *record* may contain a traditional constructor with zero arguments 
> to perform further initialization. 
> A *record* body may also declare properties whose values are only 
> mutable during a constructor call. At any other time, the property is 
> immutable. 


Talking of constructors, I find the proposed syntax rather confusing, 
because it's doing the same job as constructor property promotion, but 
in almost the opposite way: taking things out of the constructor 
signature, vs putting them in:

readonly class Foo {
    public string $bytes;
    public function __construct(public int $len) {
        $this->bytes = random_bytes($this->len);
    }
}

record Foo (int $len) {
    public string $bytes;
    public function __construct() {
        $this->bytes = random_bytes($this->len);
    }
}

While writing this example, I realised that the behaviour is also 
confusing: when exactly will the constructor be called? Consider:

$a = &Foo(42); // new Record; constructor called
$b = &Foo(42); // re-use cached Record; is the constructor skipped? or 
called, but the result discarded? what if the constructor modifies 
$this->len?
unset($a, $b);
$c = &Foo(42); // does this re-use the Record? or has it been garbage 
collected, so this will call the constructor again?


I think we should decide between two paths:

- structs/records as a special kind of object, keeping as much behaviour 
and syntax from classes as we can; that means no "inline constructor", 
and probably no "pull a cached instance from memory"
- structs/records as a brand new thing, with new syntax that only allows 
the parts that fit the model; that means no non-constructor properties, 
and no constructor bodies


Regards,

-- 
Rowan Tommins
[IMSoP]

--------------rQWv1780KumNh803ioZG0gL4
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>
    <div class="moz-cite-prefix">Hi Rob,</div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">I'm torn on this one. On the one hand,
      it does look like a nice solution for adding custom value objects
      to the language; on the other hand, it's a lot of things that are
      "just slightly different" for users to get used to.<br>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">On 17/11/2024 21:30, Rob Landers wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:ab3e32e0-1e1b-438c-a00b-cfe0cdd0f464@app.fastmail.com">One
      of the main reasons for the alternative creation syntax is because
      I felt that "new" was misleading at best, and just plain wrong at
      worst. It is also why I chose "&amp;", to make it clear you are
      not getting "a new one" but one that "just happens to exist with
      the values you asked for." I'd be open to a different keyword or
      something else entirely. It's just that "new" is the wrong one for
      records.</blockquote>
    <p><br>
    </p>
    <p>I'm not convinced by this, because I'm not convinced the "mental
      model" in the RFC is the one that most developers need to care
      about. I think a much simpler mental model (for someone who
      understands the rest of PHP) is:<br>
    </p>
    <p>- records are copy-on-write (like arrays, not like objects)<br>
      - the === operator returns true for two records with the same
      value (again like arrays, not like objects)<br>
      - the implementation optimises two records with the same values to
      share memory</p>
    <p><br>
    </p>
    <p>The third point is useful to know if you're creating a lot of
      them, but probably irrelevant most of the time. </p>
    <p>We also might not want to make it a hard guarantee, because there
      may be cases where a different trade-off is more efficient. For
      instance, maybe we will optimise $foo-&gt;with(a: 1)-&gt;with(b:
      2)-&gt;with(c: 3) to overwrite values in-place, at the cost of an
      extra condition in the `===` implementation.</p>
    <p>That would be similar to some of the changes to zvals in PHP 7;
      for instance, "$foo=42; $bar=$foo;" will copy the value 42 to a
      new piece of memory, not increase a zval reference count as PHP 5
      would have done.<br>
    </p>
    <p><br>
    </p>
    <p>That leaves the mental model as mostly "records are a bit like
      arrays". Now, it's true that we don't write "new array(1,2,3)";
      but I have heard people calling the "array()" syntax "the array
      constructor", and the manual describes it as "creating an array".
      Similarly, you use "constructor" and "construction" throughout the
      RFC.</p>
    <p>All of that makes it feel perfectly natural for me to have "new
      Point(1, 5)" mean "create a Point record; feel free to save memory
      by reusing one with the same values".<br>
    </p>
    <p><br>
    </p>
    <p>
      <blockquote type="cite">A <strong>record</strong> may contain a
        traditional constructor with zero arguments to perform further
        initialization.
      </blockquote>
      <blockquote type="cite">A <strong>record</strong> body may also
        declare properties whose values are only mutable during a
        constructor call. At any other time, the property is immutable.
      </blockquote>
    </p>
    <p><br>
    </p>
    <p>Talking of constructors, I find the proposed syntax rather
      confusing, because it's doing the same job as constructor property
      promotion, but in almost the opposite way: taking things out of
      the constructor signature, vs putting them in:<br>
    </p>
    <p>readonly class Foo { <br>
         public string $bytes;<br>
         public function __construct(public int $len) {<br>
             $this-&gt;bytes = random_bytes($this-&gt;len);<br>
         }<br>
      }</p>
    <p>record Foo (int $len) { <br>
         public string $bytes;<br>
         public function __construct() {<br>
             $this-&gt;bytes = random_bytes($this-&gt;len);<br>
         }<br>
      }</p>
    <p>While writing this example, I realised that the behaviour is also
      confusing: when exactly will the constructor be called? Consider:</p>
    <p>$a = &amp;Foo(42); // new Record; constructor called<br>
      $b = &amp;Foo(42); // re-use cached Record; is the constructor
      skipped? or called, but the result discarded? what if the
      constructor modifies $this-&gt;len?<br>
      unset($a, $b);<br>
      $c = &amp;Foo(42); // does this re-use the Record? or has it been
      garbage collected, so this will call the constructor again?<br>
    </p>
    <p><br>
    </p>
    <p>I think we should decide between two paths:</p>
    <p>- structs/records as a special kind of object, keeping as much
      behaviour and syntax from classes as we can; that means no "inline
      constructor", and probably no "pull a cached instance from memory"<br>
      - structs/records as a brand new thing, with new syntax that only
      allows the parts that fit the model; that means no non-constructor
      properties, and no constructor bodies<br>
    </p>
    <p><br>
    </p>
    <p>Regards,</p>
    <pre class="moz-signature" cols="72">-- 
Rowan Tommins
[IMSoP]</pre>
  </body>
</html>

--------------rQWv1780KumNh803ioZG0gL4--