Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122509
Feedback-ID: id5114917:Fastmail
Message-ID: <876aff9f-3eae-4d2d-8e3f-30dfbbeed49c@rwec.co.uk>
Date: Mon, 26 Feb 2024 22:46:13 +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>
 <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>
In-Reply-To: <95e93cb9-3ab0-4cf3-8ec5-83e74c9dd607@genkgo.nl>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

On 26/02/2024 20:21, Frederik Bosch wrote:
> I do note that $this->propName might suggest that the backing value is 
> accessible from other locations than only the property's own get/set 
> methods, because of $this usage. 


Yes, I actually stumbled over that confusion when I was writing some of 
the examples in my lengthy e-mail in this thread. As I understand it, 
this would work:

public string $foo {
     get { $this->foo ??= 0; $this->foo++; return $this->foo; }
     set { throw new Exception; }
}

Outside the hooks, trying to write to $this->foo would throw the 
exception, because it refers to the hooked property as a whole; but 
inside, the same name refers to something different, which isn't 
accessible anywhere else.

Now that I've looked more at how Kotlin uses "field", I understand why 
it makes sense - it's not an alias for the property itself, but the way 
to access a "backing store" which has no other name.

Using $this->foo as the name is tempting if you think of hooks as 
happening "on top of" the "real" property; but that would be a different 
feature, like Switft's "property observers" (willSet and didSet). What's 
really happening is that we're declaring two things at once, and giving 
them the same name; almost as if we'd written this:

public string $foo {
     get { static $_foo; $_foo ??= 0; $_foo++; return $_foo; }
     set { throw new Exception; }
}

Kotlin's "field" is kind of the equivalent of that "static $_foo"



> Regarding returning void=null, this is something that IDE and static 
> analyzers already pick-up as an error. I think being stricter on that 
> in this RFC would actually make sense, and treat void not as null.
>

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;"


> And why yield is magic, I do not get that. The word and the expression 
> actually expresses that something is, well, yielded.
>

But yielded to where? My mental model of "return to set" is that this:

public string $name { set($value) { $x = something($value); return $x + 
1; } }

Is effectively:

private function _name_set($value) { $x = something($value); return $x + 
1; } }
plus:
$this->name = $this->_name_set($value);

With "yield", I can't picture that simple translation; the "magic" is 
whatever translates the "yield" keyword into "$this->name ="

I would file it with the type widening in the RFC: seems kind of cool, 
but probably isn't worth the added complexity.


Regards,

-- 
Rowan Tommins
[IMSoP]