Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122513
Message-ID: <a8bdf9d6-d2ca-448e-8921-3a907e68f735@genkgo.nl>
Date: Tue, 27 Feb 2024 11:01:17 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
Content-Language: en-US, nl-NL
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>, internals@lists.php.net
References: <fca97d6c-d4ec-4000-958a-72c32beb8421@app.fastmail.com>
 <CAJp_myUayeQ=irpFUG0OrUj=PjE3_mx395h_ARSdLmdyEB6_EQ@mail.gmail.com>
 <790b5b4e-f51b-4050-a12a-5fa903d0568f@app.fastmail.com>
 <52C6F501-8E23-42D7-8541-88A22AD79375@koalephant.com>
 <36e90d8d-d275-4ce9-9dd9-1e2422c6d3a9@app.fastmail.com>
 <2fdf1933-b51c-40cc-8d02-31899b96c71c@genkgo.nl>
 <d4832238-7af4-4bd4-b8a1-8ab8d56d51d2@rwec.co.uk>
 <95e93cb9-3ab0-4cf3-8ec5-83e74c9dd607@genkgo.nl>
 <876aff9f-3eae-4d2d-8e3f-30dfbbeed49c@rwec.co.uk>
 <963f5cc5-cdb1-4384-b519-5cb15640654e@genkgo.nl>
 <58B82A81-8A89-4F17-B982-7FC36404032E@rwec.co.uk>
In-Reply-To: <58B82A81-8A89-4F17-B982-7FC36404032E@rwec.co.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: f.bosch@genkgo.nl (Frederik Bosch)


On 27-02-2024 10:49, Rowan Tommins [IMSoP] wrote:
> On 26 February 2024 23:11:16 GMT, Frederik Bosch <f.bosch@genkgo.nl> 
> wrote:
>
> >And what happens in the following situation, how are multiple get 
> calls working together?
> >
> >public string $fullName {
> >    get => $this->first . ' ' . $this->last; // is this accessing the 
> backed value, or is it accessing via get
> >    set($value) => $this->fullName = $value;
> >}
> >
> >public string $first {
> >    get => explode(' ', $this->fullName)[0], // is this accessing the 
> backed value, or is it accessing via get
> >    set($value) => $value;
> >}
>
> I don't think it's *that* confusing - the rule is not "hooks vs 
> methods", it's "special access inside the property's own hook". But as 
> I say, I'm coming around to the idea that using a different name for 
> that "backing field" / "raw value" might be sensible.
>
>
> >> What would happen if a setter contained both "return 42;" and 
> "return;"? The latter is explicitly allowed in "void" functions, but 
> is also allowed in a non-void function as meaning "return null;"
> >return 42; // returns (int)42
> >return; // early return, void, same as no return
> >return null; // returns null
>
> I'm not sure if you misunderstood my question, or just the context of 
> why I asked it. I'm talking about a hook like this:
>
> set($value) { if ($value) { return 42; } else { return; } }
>
> Currently, the only definition of "void" in the language is that a 
> void function must not contain an explicit return value. We could turn 
> that check around, and deduce that a certain hook is void. This hook 
> would not pass that check, so we would compile it to have an 
> assignment, and the false case would assign null to the property. To 
> avoid that, we would need some additional analysis to prove that in 
> all possible paths, a return statement with a value is reached.
>
> The alternative would be to run the code, and somehow observe that it 
> "returned void". But "void" isn't a value we can represent at 
> run-time; we would need to set the return value to some special value 
> just for this specific case. We would have to turn that on just for 
> hook bodies, as returning it from normal functions would be a huge BC 
> break, and also not very useful - with union types, there would be 
> plenty of better options for a function to indicate a return value 
> that needs special handling.
>
>
>
> >$generator = setCall($class, 'first', $value);
> >foreach ($generator as $value) {
> >   writeProperty($class, 'first', $value);
> >}
> >if ($generator->hasReturn()) {
> >writeProperty($class, 'first', $generator->getReturn());
> >}
>
>
> That's already an order of magnitude more complicated than "the return 
> value is used on the right-hand side of an assignment", and it's 
> missing at least one case: set($value) { return $value; } will not 
> compile to a generator, so needs to skip and assign the value directly.
>
> By "magic", what I meant was "hidden logic underneath that makes it 
> work". Assign-by-return has a small amount of magic - you can express 
> it in half a line of code; assign-by-yield has much more magic - a 
> whole bunch of loops and conditionals to operate your coroutine.
>
>
>
> > The yield is much more intuitive than magic fields
>
> I think we'll just have to differ in opinion on that one. Maybe you're 
> just more used to working with coroutines than I am.
>
> Note that yield also doesn't solve how to read the current backing 
> value in a get hook (or a set hook that wants to compare before and 
> after), so we still need some way to refer to it.
>
> Regards,
> Rowan Tommins
> [IMSoP]

Hi Rowan,

Our discussion sums up the pros and cons. Whether yield is 
complicated/confusing or not, is maybe personal. The same applies to 
getting $this->prop resulting in different calls. Larry has removed 
$field from the RFC completely now, while I think it was a sensible 
approach to read the current backing value. I think I have laid out 
another alternative to writing with the yield/return suggestion. It's up 
to the authors of the RFC to do something with it, or not. Thanks for 
taking the suggestion seriously.

Regards,
Frederik