Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122523
Feedback-ID: ifab94697:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-182-gaab6630818-fm-20240222.002-gaab66308
Precedence: bulk
MIME-Version: 1.0
Message-ID: <aab337f1-da7b-4232-8d22-f7d7361f9bd4@app.fastmail.com>
In-Reply-To: <b59c4e85-bede-4fe3-840b-b168d280fe17@app.fastmail.com>
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>
 <a8bdf9d6-d2ca-448e-8921-3a907e68f735@genkgo.nl>
 <b59c4e85-bede-4fe3-840b-b168d280fe17@app.fastmail.com>
Date: Tue, 27 Feb 2024 21:23:26 +0100
To: "Larry Garfield" <larry@garfieldtech.com>,
 "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
Content-Type: multipart/alternative;
 boundary=cbdc3d185cb640d0bfc5f48556a0e9d7
From: rob@bottled.codes ("Rob Landers")

--cbdc3d185cb640d0bfc5f48556a0e9d7
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tue, Feb 27, 2024, at 17:16, Larry Garfield wrote:
> On Tue, Feb 27, 2024, at 10:01 AM, Frederik Bosch wrote:
>=20
> > Hi Rowan,
> >
> > Our discussion sums up the pros and cons. Whether yield is=20
> > complicated/confusing or not, is maybe personal. The same applies to=20
> > getting $this->prop resulting in different calls. Larry has removed=20
> > $field from the RFC completely now, while I think it was a sensible=20
> > approach to read the current backing value. I think I have laid out=20
> > another alternative to writing with the yield/return suggestion. It'=
s up=20
> > to the authors of the RFC to do something with it, or not. Thanks fo=
r=20
> > taking the suggestion seriously.
> >
> > Regards,
> > Frederik
>=20
> 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 involv=
ed in hooks at all, and a syntax that implies there is would be very mis=
leading.  And adjusting the code to make it actually generator-based wou=
ld 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 cour=
se of its lifetime.

> It figures that people would start speaking up in favor of $field righ=
t *after* I removed it from the RFC text. :-P  At the moment, we're comf=
ortable 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, rea=
lly 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 probab=
ly start a poll shortly to help get a better sense of what the actual vo=
ting 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.

>=20
> --Larry Garfield
>=20

=E2=80=94 Rob
--cbdc3d185cb640d0bfc5f48556a0e9d7
Content-Type: text/html;charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div>On Tue, Feb 27,=
 2024, at 17:16, Larry Garfield wrote:<br></div><blockquote type=3D"cite=
" id=3D"qt" style=3D""><div>On Tue, Feb 27, 2024, at 10:01 AM, Frederik =
Bosch wrote:<br></div><div><br></div><div>&gt; Hi Rowan,<br></div><div>&=
gt;<br></div><div>&gt; Our discussion sums up the pros and cons. Whether=
 yield is&nbsp;<br></div><div>&gt; complicated/confusing or not, is mayb=
e personal. The same applies to&nbsp;<br></div><div>&gt; getting $this-&=
gt;prop resulting in different calls. Larry has removed&nbsp;<br></div><=
div>&gt; $field from the RFC completely now, while I think it was a sens=
ible&nbsp;<br></div><div>&gt; approach to read the current backing value=
. I think I have laid out&nbsp;<br></div><div>&gt; another alternative t=
o writing with the yield/return suggestion. It's up&nbsp;<br></div><div>=
&gt; to the authors of the RFC to do something with it, or not. Thanks f=
or&nbsp;<br></div><div>&gt; taking the suggestion seriously.<br></div><d=
iv>&gt;<br></div><div>&gt; Regards,<br></div><div>&gt; Frederik<br></div=
><div><br></div><div>Ilija and I have discussed this, and we both agree =
that yield is not a viable option.&nbsp; There is no generator or genera=
tor-like behavior involved in hooks at all, and a syntax that implies th=
ere is would be very misleading.&nbsp; And adjusting the code to make it=
 actually generator-based would make the code considerably more complex,=
 and most likely slower.<br></div></blockquote><div><br></div><div>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 value=
s through the function lifetime. A normal function only exposes one valu=
e -- 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.</div><div><br></div><blockquote type=3D"cite" id=3D"qt" s=
tyle=3D""><div>It figures that people would start speaking up in favor o=
f $field right *after* I removed it from the RFC text. :-P&nbsp; At the =
moment, we're comfortable either direction.&nbsp; (It hasn't been remove=
d from the code yet.)&nbsp; The main question is whether the trade-off o=
f an implicit variable name and the potential for confusion is outweighe=
d by the clarity about what is happening and where.&nbsp; 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 rep=
lies to an email."&nbsp; I will probably start a poll shortly to help ge=
t a better sense of what the actual voting population thinks.<br></div><=
/blockquote><div><br></div><div>I suspect that people who are for it mig=
ht also happen to be Gmail users. Also, I don't feel particularly strong=
ly either way, nor am I a voter, so I haven't said anything one way or t=
he other.<br></div><div><br></div><blockquote type=3D"cite" id=3D"qt" st=
yle=3D""><div><br></div><div>--Larry Garfield<br></div><div><br></div></=
blockquote><div><br></div><div id=3D"sig121229152">=E2=80=94 Rob<br></di=
v></body></html>
--cbdc3d185cb640d0bfc5f48556a0e9d7--