Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124056
Feedback-ID: ifab94697:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-538-g1508afaa2-fm-20240616.001-g1508afaa
Precedence: bulk
MIME-Version: 1.0
Message-ID: <48b32b60-3935-4296-af84-f41953addcdf@app.fastmail.com>
In-Reply-To: <A98AB87D-3340-4A64-A790-C1C9B727EC10@php.net>
References: <90dd3eb6-c7be-4951-a6b6-fd3785ed92e5@app.fastmail.com>
 <89C9AC15-1456-46AE-9183-DFDA7D0D381D@sakiot.com>
 <afb0c41a-5189-4845-b978-ac4e67e30e99@app.fastmail.com>
 <A98AB87D-3340-4A64-A790-C1C9B727EC10@php.net>
Date: Sat, 29 Jun 2024 19:56:43 +0200
To: "Ben Ramsey" <ramsey@php.net>, "Larry Garfield" <larry@garfieldtech.com>
Cc: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Operator Overrides -- Lite Edition
Content-Type: multipart/alternative;
 boundary=5d1dd10558094eaab64e7105a6978b46
From: rob@bottled.codes ("Rob Landers")

--5d1dd10558094eaab64e7105a6978b46
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Sat, Jun 29, 2024, at 17:37, Ben Ramsey wrote:
> > On Jun 29, 2024, at 10:16, Larry Garfield <larry@garfieldtech.com> w=
rote:
> >=20
> > For clarity (since I know from experience it's helpful to RFC author=
s to have a concrete sense of votes in advance): I will be voting No on =
this RFC.  As both Jordan and Saki have explained, it's a hideous hack t=
hat doesn't look like it would even work, much less be wise.  I'd much r=
ather take a second swing at Jordan's original operator overloading RFC,=
 which I supported and still support.  Let's do it right.
>=20
>=20
> I agree with Larry that I would rather take another look at an overall=
 operator overloading RFC than to implement this in one specific extensi=
on.
>=20
> Cheers,
> Ben
>=20

Thank you Larry and Ben, I appreciate it. Out of curiosity, do you consi=
der ArrayAccess and Stringable a hideous hack too?

=E2=80=94 Rob

--5d1dd10558094eaab64e7105a6978b46
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 Sat, Jun 29,=
 2024, at 17:37, Ben Ramsey wrote:<br></div><blockquote type=3D"cite" id=
=3D"qt" style=3D""><div>&gt; On Jun 29, 2024, at 10:16, Larry Garfield &=
lt;<a href=3D"mailto:larry@garfieldtech.com">larry@garfieldtech.com</a>&=
gt; wrote:<br></div><div>&gt;&nbsp;<br></div><div>&gt; For clarity (sinc=
e I know from experience it's helpful to RFC authors to have a concrete =
sense of votes in advance): I will be voting No on this RFC.&nbsp; As bo=
th Jordan and Saki have explained, it's a hideous hack that doesn't look=
 like it would even work, much less be wise.&nbsp; I'd much rather take =
a second swing at Jordan's original operator overloading RFC, which I su=
pported and still support.&nbsp; Let's do it right.<br></div><div><br></=
div><div><br></div><div>I agree with Larry that I would rather take anot=
her look at an overall operator overloading RFC than to implement this i=
n one specific extension.<br></div><div><br></div><div>Cheers,<br></div>=
<div>Ben<br></div><div><br></div></blockquote><div><br></div><div><div>T=
hank you Larry and Ben, I appreciate it. Out of curiosity, do you consid=
er ArrayAccess and Stringable a hideous hack too?<br></div><div><br></di=
v><div>=E2=80=94 Rob<br></div></div><div><br></div></body></html>
--5d1dd10558094eaab64e7105a6978b46--