Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122628
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-251-g8332da0bf6-fm-20240305.001-g8332da0b
Precedence: bulk
MIME-Version: 1.0
Message-ID: <7eada0fd-39c5-4a89-8c74-80c671801a2d@app.fastmail.com>
In-Reply-To: <c057b162-e2fe-4ade-b27f-e09815743748@rwec.co.uk>
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>
Date: Tue, 12 Mar 2024 22:43:46 +0000
To: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
Content-Type: text/plain
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, Mar 12, 2024, at 10:09 PM, Rowan Tommins [IMSoP] wrote:

>> 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.

It's slightly different, yes.  The point is that the special behavior of a hook is disabled if you are within the call stack of a hook, just like the special behavior of __get/__set is disabled if you are within the call stack of __get/__set.  What happens when you hit an operation that would otherwise go into an infinite loop is a bit different, but the "disable to avoid an infinite loop" logic is the same.

So maybe "is the same" rather than "is identical", but otherwise it's the same concept.

>> 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.

The point is to give the user the option for full backwards compatibility when it makes sense. This requires jumping through some hoops, which is the point. This is essentially equivalent to creating a by-ref getter + a setter, exposing the underlying property. By creating a virtual property, we are "accepting" that the two are detached. While we could disallow this, we recognize that there may be valid use-cases that we'd like to enable.  It also parallels __get/__set, where using &__get means you can write to something without going through __set.

In practice I expect it virtual properties with both hooks to be very rare.  Most virtual properties will, I expect, be lazy-computed get-only values.

>> 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.

With the change to allow &get in the absence of set, I believe that would already work.  

cf: https://3v4l.org/3Gnti/rfc#vrfc.property-hooks

>> 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; 
>    } 
> }

That would be legal.


>> 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();

Hm.  Good point here.  We'll probably need to add another method to ReflectionProperty for that.  Stay tuned.

--Larry Garfield