Re: [RFC[ Property accessor hooks, take 2

From: Date: Tue, 27 Feb 2024 20:23:26 +0000
Subject: Re: [RFC[ Property accessor hooks, take 2
References: 1 2 3 4 5 6 7 8 9 10 11 12 13  Groups: php.internals 
Request: Send a blank email to internals+get-122523@lists.php.net to get a copy of this message
On Tue, Feb 27, 2024, at 17:16, Larry Garfield wrote: > On Tue, Feb 27, 2024, at 10:01 AM, Frederik Bosch wrote: > > > 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 > > Ilija and I have discussed this, and we both agree that yield is not a viable option. There is > no generator or generator-like behavior involved in hooks at all, and a syntax that implies there is > would be very misleading. And adjusting the code to make it actually generator-based would make the > code considerably more complex, and most likely slower. If it makes the code more complex, then it probably shouldn't be there. AFAIK saying there isn't generator-like behavior, I would disagree. The value (in this case) is exactly like an iterator, and may have multiple values through the function lifetime. A normal function only exposes one value -- the return value -- unless it exports values out of its scope using references. Only a generator exposes multiple values over the course of its lifetime. > It figures that people would start speaking up in favor of $field right *after* I removed it > from the RFC text. :-P At the moment, we're comfortable either direction. (It hasn't > been removed from the code yet.) The main question is whether the trade-off of an implicit variable > name and the potential for confusion is outweighed by the clarity about what is happening and where. > It sounds like most people are just really, really pissed off by an implicit variable, but > that's based on the as-usual highly unscientific survey of "who replies to an email." > I will probably start a poll shortly to help get a better sense of what the actual voting > population thinks. I suspect that people who are for it might also happen to be Gmail users.. Also, I don't feel particularly strongly either way, nor am I a voter, so I haven't said anything one way or the other. > > --Larry Garfield > — Rob

« previous php.internals (#122523) next »