Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122661
Feedback-ID: id5114917:Fastmail
Content-Type: multipart/alternative;
 boundary="------------pstL870mxy142bejb5Zclpri"
Message-ID: <f95527c0-a0d5-48da-a071-ce1c4ffe6814@rwec.co.uk>
Date: Sat, 16 Mar 2024 19:22:42 +0000
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
To: internals@lists.php.net
References: <fca97d6c-d4ec-4000-958a-72c32beb8421@app.fastmail.com>
 <a715dacb-9bac-4bea-a2bb-c623737fd81e@app.fastmail.com>
 <c057b162-e2fe-4ade-b27f-e09815743748@rwec.co.uk>
 <7eada0fd-39c5-4a89-8c74-80c671801a2d@app.fastmail.com>
 <1698692e-8eb1-4bfc-a743-375696cd8f1c@rwec.co.uk>
 <154481e0-5f62-4026-994a-28a644d71527@app.fastmail.com>
 <C517590C-77D1-462C-92E9-D2851345BE67@rwec.co.uk>
 <e18863f1-9cc9-400b-b6b4-d1be62fa4d0f@app.fastmail.com>
 <46609F15-DD40-4BD2-A78A-16021C3447C8@rwec.co.uk>
 <CAPyj-LBEzCNzWkh8qwfBrC-ccMKFANX=zwNq9O0qSnNdFNjtzw@mail.gmail.com>
Content-Language: en-GB
In-Reply-To: <CAPyj-LBEzCNzWkh8qwfBrC-ccMKFANX=zwNq9O0qSnNdFNjtzw@mail.gmail.com>
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

This is a multi-part message in MIME format.
--------------pstL870mxy142bejb5Zclpri
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 16/03/2024 17:51, Ilija Tovilo wrote:
> Properties can inherit both storage and hooks from their parent.
> Hopefully, that helps with the mental model. Of course, in reality it
> is a bit more complicated due to guards and references.


That is a really helpful explanation, thanks; I hadn't thought about the 
significance of inheritance between hooked and non-hooked properties.

I still think there will be a lot of users coming from other languages, 
or from using __get and __set, who will look at virtual properties 
first. Making things less surprising for those people seems worth some 
effort, but I'm not asking for a complete redesign.



> Dynamic properties are not particularly relevant today. The point was
> not to show how similar these two cases are, but to explain that
> there's an existing mechanism in place that works very well for hooks.
> We may invent some new mechanism to access the backing value, like
> `field = 'value'`, but for what reason? This would only make sense if
> the syntax we use is useful for something else. However, given that
> without guards it just leads to recursion, which I really can't see
> any use for, I don't see the point.


I can think of several reasons we *could* explore other syntax:

1) To make it clearer in code whether a particular line is accessing via 
the hooks, or by-passing them 2) To make the code in the hooks shorter 
(e.g. `$field` is significantly shorter than 
`$this->someDescriptiveName`) 3) To allow code to by-pass the hooks at 
will, rather than only when called from the hooks (e.g. having a single 
method that resets the state of several lazy-loaded properties)

Those reasons are probably not enough to rule out the current syntax; 
but they show there are trade-offs being made.

To be honest, my biggest hesitation with the RFC remains asymmetric 
types (the ability to specify types in the set hook). It's quite a 
significant feature, with no precedent I know of, and I'm worried we'll 
overlook something by including it immediately. For instance, what will 
be the impact on people using reflection or static analysis to reason 
about types? I would personally be more comfortable leaving that to a 
follow-up RFC to consider the details more carefully.

Nobody else has raised that, beyond the syntax; I'm not sure if that's 
because everyone is happy with it, or because the significance has been 
overlooked.


Regards,

-- 
Rowan Tommins
[IMSoP]

--------------pstL870mxy142bejb5Zclpri
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 16/03/2024 17:51, Ilija Tovilo
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAPyj-LBEzCNzWkh8qwfBrC-ccMKFANX=zwNq9O0qSnNdFNjtzw@mail.gmail.com"><span
      style="white-space: pre-wrap">
</span>
      <pre class="moz-quote-pre" wrap="">Properties can inherit both storage and hooks from their parent.
Hopefully, that helps with the mental model. Of course, in reality it
is a bit more complicated due to guards and references.</pre>
    </blockquote>
    <p><br>
    </p>
    <p>That is a really helpful explanation, thanks; I hadn't thought
      about the significance of inheritance between hooked and
      non-hooked properties.<br>
    </p>
    <p>I still think there will be a lot of users coming from other
      languages, or from using __get and __set, who will look at virtual
      properties first. Making things less surprising for those people
      seems worth some effort, but I'm not asking for a complete
      redesign.<br>
    </p>
    <p><br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite"
cite="mid:CAPyj-LBEzCNzWkh8qwfBrC-ccMKFANX=zwNq9O0qSnNdFNjtzw@mail.gmail.com"><span
      style="white-space: pre-wrap">
</span>
      <pre class="moz-quote-pre" wrap="">Dynamic properties are not particularly relevant today. The point was
not to show how similar these two cases are, but to explain that
there's an existing mechanism in place that works very well for hooks.
We may invent some new mechanism to access the backing value, like
`field = 'value'`, but for what reason? This would only make sense if
the syntax we use is useful for something else. However, given that
without guards it just leads to recursion, which I really can't see
any use for, I don't see the point.</pre>
    </blockquote>
    <p><br>
    </p>
    <p><span style="white-space: pre-wrap">I can think of several reasons we *could* explore other syntax:</span></p>
    <p><span style="white-space: pre-wrap">1) To make it clearer in code whether a particular line is accessing via the hooks, or by-passing them
2) To make the code in the hooks shorter (e.g. `$field` is significantly shorter than `$this-&gt;someDescriptiveName`)
3) To allow code to by-pass the hooks at will, rather than only when called from the hooks (e.g. having a single method that resets the state of several lazy-loaded properties)
</span></p>
    <p><span style="white-space: pre-wrap">Those reasons are probably not enough to rule out the current syntax; but they show there are trade-offs being made.
</span></p>
    <p><span style="white-space: pre-wrap">
</span></p>
    <p><span style="white-space: pre-wrap">
</span></p>
    <p>To be honest, my biggest hesitation with the RFC remains
      asymmetric types (the ability to specify types in the set hook).
      It's quite a significant feature, with no precedent I know of, and
      I'm worried we'll overlook something by including it immediately.
      For instance, what will be the impact on people using reflection
      or static analysis to reason about types? I would personally be
      more comfortable leaving that to a follow-up RFC to consider the
      details more carefully.</p>
    <p>Nobody else has raised that, beyond the syntax; I'm not sure if
      that's because everyone is happy with it, or because the
      significance has been overlooked.<br>
    </p>
    <p><br>
    </p>
    <p>Regards,<br>
    </p>
    <pre class="moz-signature" cols="72">-- 
Rowan Tommins
[IMSoP]</pre>
  </body>
</html>

--------------pstL870mxy142bejb5Zclpri--