Re: [RFC[ Property accessor hooks, take 2
| From: | Rob Landers | 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