Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122627
Feedback-ID: id5114917:Fastmail
Content-Type: multipart/alternative;
 boundary="------------bEerQroA3mRy3S5F40wCpqlj"
Message-ID: <c057b162-e2fe-4ade-b27f-e09815743748@rwec.co.uk>
Date: Tue, 12 Mar 2024 22:09:21 +0000
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
Content-Language: en-GB
To: internals@lists.php.net
References: <fca97d6c-d4ec-4000-958a-72c32beb8421@app.fastmail.com>
 <a715dacb-9bac-4bea-a2bb-c623737fd81e@app.fastmail.com>
In-Reply-To: <a715dacb-9bac-4bea-a2bb-c623737fd81e@app.fastmail.com>
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

This is a multi-part message in MIME format.
--------------bEerQroA3mRy3S5F40wCpqlj
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 08/03/2024 15:53, Larry Garfield wrote:
> Hi folks.  Based on earlier discussions, we've made a number of changes
> to the RFC that should address some of the concerns people raised.  We
> also had some very fruitful discussions off-list with several developers
>   from the Foundation, which led to what we feel are some solid
> improvements.
>
> https://wiki.php.net/rfc/property-hooks


Hi Larry,

Thanks again for the continuing hard work on this!


 > if a |get| hook for property |$foo| calls method |bar()|, then inside 
that method |$this->foo| will refer to the raw property, both read and 
write. If |bar()| is called from somewhere other than the hook, reading 
from |$this->foo| will trigger the |get| hook. This behavior is 
identical to that already used by |__get| and |__set| today.


I'm slightly confused by this.

If there is an actual property called $foo, then __get and __set will be 
called only when it is out of visibility, regardless of the call stack - 
e.g. a private property will always trigger __get from public scope, and 
always access it directly from private scope: https://3v4l.org/R5Yos 
That seems differ from what's proposed, where even a private call to 
bar() would trigger the hook.

The protection against recursion appears to only be relevant for 
completely undefined properties. For __get, the direct access can never 
do anything useful - there's nothing to access: https://3v4l.org/2nDZS 
For __set, it is at least possible for the non-recursive write to 
succeed, but only in the niche case of creating a dynamic property: 
https://3v4l.org/dpYOj I'm not sure that there's any equivalent to this 
scenario for property hooks, since they can never be undefined/dynamic.



 > There is one exception to the above: if a property is virtual, then 
there is no presumed connection between the get and set operations. 
[...] For that reason, |&get| by reference is allowed for virtual 
properties, regardless of whether or not there is a |set| hook.


I don't agree with this, and the example immediately following it 
demonstrates the exact opposite: the &get and set hooks are both 
proxying to the same backing value, and have all the same problems as if 
the property was non-virtual. I would imagine a lot of real-life virtual 
properties would be doing something similar: converting to/from a 
different type, proxying to another object, etc.

I think this exception is unnecessarily complicated: either trust users 
to handle the implications of combining &get with set, or forbid it.



 > Additionally, |&get| hooks are allowed for arrays as well, provided 
there is no |set| hook.


I mentioned in a previous e-mail the possibility of using the &get hook 
for array writes. Has this been considered?

That is:

$c->arr['beep'] = 'boop';

Would be equivalent to:

$temp =& $c->arr;
$temp['beep'] = 'boop';
unset($temp);

Which would be valid if $arr had an &get hook defined.



 > A |set| hook on a typed property must declare a parameter type that 
is the same as or contravariant (wider) from the type of the property.

 > Once a property has both a |get| and |set| operation, however, it is 
no longer covariant or contravariant for further extension.


How do these two rules interact?

Could this:

public string $foo {
    get => $this->_foo;
    set(string|Stringable $value) {
        $this->_foo = (string)$value;
    }
}

be over-ridden by this, where the property's "main type" remains 
invariant but its "settable type" is contravariant?

public string $foo {
    get => $this->_foo;
    set(string|Stringable|SomethingElse $value) {
        $this->_foo = $value instanceof SomethingElse ? 
$value->asString() : (string)$value;
    }
}


 > ReflectionProperty has several new methods to work with hooks.


There should be some way to reliably determine the "settable type" of a 
property. At the moment, I think you would have to do something like this:

$setHook = $property->getHook(PropertyHookType::Set);
$writeType = $setHook === null ? $property->getType() 
: $setHook->getParameters()[0]->getType();



Once again, I would like to make the case that asymmetric types are an 
unnecessary complication that should be left to Future Scope.

The fact that none of the other languages referenced have such a feature 
should also give us pause. There's nothing to stop us being the first to 
innovate a feature, but we should be extra cautious when doing so, with 
no previous experience to learn from. It also means there is no 
expectation from users coming from other languages that this will be 
possible.

If it genuinely seems useful, it can be added in a follow-up RFC, or 
even a later version of PHP, with little impact on the rest of the 
feature. But if we add it now and regret it, or some detail of its 
implementation, we will be stuck with it forever.


Regards,

-- 
Rowan Tommins
[IMSoP]

--------------bEerQroA3mRy3S5F40wCpqlj
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">On 08/03/2024 15:53, Larry Garfield
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:a715dacb-9bac-4bea-a2bb-c623737fd81e@app.fastmail.com">
      <pre>Hi folks.  Based on earlier discussions, we've made a number of changes 
to the RFC that should address some of the concerns people raised.  We 
also had some very fruitful discussions off-list with several developers
 from the Foundation, which led to what we feel are some solid 
improvements.

<a class="moz-txt-link-freetext"
      href="https://wiki.php.net/rfc/property-hooks"
      moz-do-not-send="true">https://wiki.php.net/rfc/property-hooks</a></pre>
    </blockquote>
    <p><br>
    </p>
    <p>Hi Larry,</p>
    <p>Thanks again for the continuing hard work on this!</p>
    <p><br>
    </p>
    <p>&gt; if a <code>get</code> hook for property <code
        class="code php"><span class="re0">$foo</span></code> calls
      method <code class="code php">bar<span class="br0">(</span><span
          class="br0">)</span></code>, then inside that method <code
        class="code php"><span class="re0">$this</span><span class="sy0">-&gt;</span><span
          class="me1">foo</span></code> will refer to the raw property,
      both read and write. If <code class="code php">bar<span
          class="br0">(</span><span class="br0">)</span></code> is
      called from somewhere other than the hook, reading from <code
        class="code php"><span class="re0">$this</span><span class="sy0">-&gt;</span><span
          class="me1">foo</span></code> will trigger the <code>get</code>
      hook. This behavior is identical to that already used by <code
        class="code php">__get</code> and <code class="code php">__set</code>
      today. <br>
    </p>
    <p><br>
    </p>
    <p>I'm slightly confused by this.<br>
    </p>
    <p>If there is an actual property called $foo, then __get and __set
      will be called only when it is out of visibility, regardless of
      the call stack - e.g. a private property will always trigger __get
      from public scope, and always access it directly from private
      scope: <a class="moz-txt-link-freetext" href="https://3v4l.org/R5Yos">https://3v4l.org/R5Yos</a> That seems differ from what's
      proposed, where even a private call to bar() would trigger the
      hook.</p>
    <p>The protection against recursion appears to only be relevant for
      completely undefined properties. For __get, the direct access can
      never do anything useful - there's nothing to access:
      <a class="moz-txt-link-freetext" href="https://3v4l.org/2nDZS">https://3v4l.org/2nDZS</a> For __set, it is at least possible for the
      non-recursive write to succeed, but only in the niche case of
      creating a dynamic property: <a class="moz-txt-link-freetext" href="https://3v4l.org/dpYOj">https://3v4l.org/dpYOj</a> I'm not sure
      that there's any equivalent to this scenario for property hooks,
      since they can never be undefined/dynamic.<br>
    </p>
    <p><br>
    </p>
    <p><br>
    </p>
    <p>&gt; There is one exception to the above: if a property is
      virtual, then there is no presumed connection between the get and
      set operations. [...] For that reason, <code>&amp;get</code> by
      reference is allowed for virtual properties, regardless of whether
      or not there is a <code>set</code> hook. <br>
    </p>
    <p><br>
    </p>
    <p>I don't agree with this, and the example immediately following it
      demonstrates the exact opposite: the &amp;get and set hooks are
      both proxying to the same backing value, and have all the same
      problems as if the property was non-virtual. I would imagine a lot
      of real-life virtual properties would be doing something similar:
      converting to/from a different type, proxying to another object,
      etc. </p>
    <p>I think this exception is unnecessarily complicated: either trust
      users to handle the implications of combining &amp;get with set,
      or forbid it.</p>
    <p><br>
    </p>
    <p><br>
    </p>
    <p>&gt; Additionally, <code>&amp;get</code> hooks are allowed for
      arrays as well, provided there is no <code>set</code> hook.
    </p>
    <p><br>
    </p>
    <p>I mentioned in a previous e-mail the possibility of using the
      &amp;get hook for array writes. Has this been considered?</p>
    <p>That is:<br>
    </p>
    <p>$c-&gt;arr['beep'] = 'boop';</p>
    <p>Would be equivalent to:</p>
    <p>$temp =&amp; $c-&gt;arr;<br>
      $temp['beep'] = 'boop';<br>
      unset($temp);<br>
    </p>
    <p>Which would be valid if $arr had an &amp;get hook defined.<br>
    </p>
    <p><br>
    </p>
    <p><br>
    </p>
    <p>&gt; A <code class="code php">set</code> hook on a typed
      property must declare a parameter type that is the same as or
      contravariant (wider) from the type of the property. </p>
    <p>&gt; Once a property has both a <code>get</code> and <code>set</code>
      operation, however, it is no longer covariant or contravariant for
      further extension.</p>
    <p><br>
    </p>
    <p>How do these two rules interact?<br>
    </p>
    <p>Could this:</p>
    <p>public string $foo { <br>
         get =&gt; $this-&gt;_foo;<br>
         set(string|Stringable $value) {<br>
             $this-&gt;_foo = (string)$value;<br>
         } <br>
      }<br>
    </p>
    <p>be over-ridden by this, where the property's "main type" remains
      invariant but its "settable type" is contravariant?</p>
    <p>public string $foo { <br>
         get =&gt; $this-&gt;_foo;<br>
         set(string|Stringable|SomethingElse $value) {<br>
             $this-&gt;_foo = $value instanceof SomethingElse ?
      $value-&gt;asString() : (string)$value; <br>
         } <br>
      }</p>
    <p><br>
    </p>
    <p>&gt; ReflectionProperty has several new methods to work with
      hooks.</p>
    <p><br>
    </p>
    <p>There should be some way to reliably determine the "settable
      type" of a property. At the moment, I think you would have to do
      something like this:</p>
    <p>$setHook = $property-&gt;getHook(PropertyHookType::Set);<br>
      $writeType = $setHook === null ? $property-&gt;getType()
      : $setHook-&gt;getParameters()[0]-&gt;getType();<br>
    </p>
    <p><br>
    </p>
    <p><br>
    </p>
    <p>Once again, I would like to make the case that asymmetric types
      are an unnecessary complication that should be left to Future
      Scope.</p>
    <p>The fact that none of the other languages referenced have such a
      feature should also give us pause. There's nothing to stop us
      being the first to innovate a feature, but we should be extra
      cautious when doing so, with no previous experience to learn from.
      It also means there is no expectation from users coming from other
      languages that this will be possible.<br>
    </p>
    <p>If it genuinely seems useful, it can be added in a follow-up RFC,
      or even a later version of PHP, with little impact on the rest of
      the feature. But if we add it now and regret it, or some detail of
      its implementation, we will be stuck with it forever.<br>
    </p>
    <p><br>
    </p>
    <p>Regards,<br>
    </p>
    <pre class="moz-signature" cols="72">-- 
Rowan Tommins
[IMSoP]</pre>
  </body>
</html>

--------------bEerQroA3mRy3S5F40wCpqlj--