Re: [RFC[ Property accessor hooks, take 2

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]