Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124040
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-538-g1508afaa2-fm-20240616.001-g1508afaa
Precedence: bulk
MIME-Version: 1.0
Message-ID: <afb0c41a-5189-4845-b978-ac4e67e30e99@app.fastmail.com>
In-Reply-To: <89C9AC15-1456-46AE-9183-DFDA7D0D381D@sakiot.com>
References: <90dd3eb6-c7be-4951-a6b6-fd3785ed92e5@app.fastmail.com>
 <89C9AC15-1456-46AE-9183-DFDA7D0D381D@sakiot.com>
Date: Sat, 29 Jun 2024 10:16:46 -0500
To: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Operator Overrides -- Lite Edition
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Sat, Jun 29, 2024, at 7:28 AM, Saki Takamachi wrote:
> Hi,
>
>> On Sat, Jun 29, 2024, at 02:13, Jordan LeDoux wrote:
>>>>> 4. The `static` distinction is also fairly meaningless, as in PHP =
there is no situation possible where an operator overload can occur WITH=
OUT it operating on objects themselves.
>>>>=20
>>>> For this, that is the wrong approach. The actual behavior is on the=
 type, not the instance. The object instances may not even know their va=
lue, they merely represent the value.
>>>=20
>>> A GMP object instance that does not know its value? What are you eve=
n talking about? Can you show me some code explaining what you mean? I h=
ad literally months of this argument for the operator overloads RFC, and=
 studied the overload implementations in six other languages as part of =
writing that RFC, I feel like I understand this topic fairly well. But I=
 do not understand what you are saying here.
>>=20
>> A few minutes ago, I sent an email where I accidentally made the code=
 non-static, and I think I see the merit in what you are saying. It felt=
 so natural to use $this that I didn't even realize I was doing it wrong.
>>=20
>> So, looking at your RFC and mine, I think this can be improved.
>>=20
>> What would you suggest it look like and then we can work backwards fr=
om there?
>
> Here are my thoughts on your code.
>
> In theory, inheriting from this "improved GMP class" would allow=20
> overloading of computational operators.
>
> In effect, this acts like a "calcable interface", with the constructor=20
> passing in meaningless values =E2=80=8B=E2=80=8Bto the parent construc=
tor and the add=20
> method allowing the user to freely modify the return value.
>
> This means that virtually any userland class can use the operator=20
> overloading feature via a "hack".
>
> This approach is completely wrong. Rather than proposing this as is, i=
t=20
> would be more constructive to propose support for operator overloading.
>
> Regards,
>
> Saki

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 rathe=
r take a second swing at Jordan's original operator overloading RFC, whi=
ch I supported and still support.  Let's do it right.

--Larry Garfield