Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124043
Content-Type: text/plain;
	charset=us-ascii
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\))
Subject: Re: [PHP-DEV] [RFC] Operator Overrides -- Lite Edition
In-Reply-To: <afb0c41a-5189-4845-b978-ac4e67e30e99@app.fastmail.com>
Date: Sat, 29 Jun 2024 10:37:34 -0500
Cc: php internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <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>
To: Larry Garfield <larry@garfieldtech.com>
From: ramsey@php.net (Ben Ramsey)

> On Jun 29, 2024, at 10:16, Larry Garfield <larry@garfieldtech.com> =
wrote:
>=20
> For clarity (since 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.  As both Jordan and Saki have explained, it's a hideous hack =
that doesn't look like it would even work, much less be wise.  I'd much =
rather take a second swing at Jordan's original operator overloading =
RFC, which I supported and still support.  Let's do it right.


I agree with Larry that I would rather take another look at an overall =
operator overloading RFC than to implement this in one specific =
extension.

Cheers,
Ben