Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124035
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Mime-Version: 1.0 (1.0)
Subject: Re: [PHP-DEV] [RFC] Operator Overrides -- Lite Edition
In-Reply-To: <90ab0ec1-33ad-4342-ad4b-6448ee89bfa7@app.fastmail.com>
Cc: Jordan LeDoux <jordan.ledoux@gmail.com>, internals@lists.php.net
Date: Sat, 29 Jun 2024 23:19:46 +0900
Message-ID: <DD3C5488-4C11-4393-A45D-60F8C49B4DA0@sakiot.com>
References: <90ab0ec1-33ad-4342-ad4b-6448ee89bfa7@app.fastmail.com>
To: Rob Landers <rob@bottled.codes>
From: saki@sakiot.com (Saki Takamachi)

Hi,

>> Here are my thoughts on your code.
>>=20
>> In theory, inheriting from this "improved GMP class" would allow overload=
ing of computational operators.
>>=20
>> In effect, this acts like a "calcable interface", with the constructor pa=
ssing in meaningless values to the parent constructor and the add method all=
owing the user to freely modify the return value.
>>=20
>> This means that virtually any userland class can use the operator overloa=
ding feature via a "hack".
>=20
> That is a very valid point, and I feel like it is something I definitely w=
ould have thought about since I love abusing features to do things they shou=
ldn't. My hope was that by removing the ability to directly compare, it woul=
d reduce the usefulness of "hacking it" into generic overloading since you h=
ave to return a GMP instance ... but then, I guess, that GMP instance techni=
cally doesn't have to represent a number (though the rest of the engine will=
 very much treat it as a number).
>=20
> I will think on this some more...
>=20
> For example, while eating lunch, I was considering whether this even needs=
 to have anything to do with the GMP instance. I was only focusing on the GM=
P class because right now, it is non-final. Then I started thinking about Jo=
rdan's original proposal and how it could be simplified ... there's certainl=
y things to think about.
>=20
>> This approach is completely wrong.
>=20
> Ouch, I would hope it would have something useful to it. :)
>=20
>>=20
>> Rather than proposing this as is, it would be more constructive to propos=
e support for operator overloading.
>=20
> That's been tried before, and this was an attempt at the far other extreme=
, "barely operator overloading". So, there is surely something in the middle=
. Hopefully.
>=20
> =E2=80=94 Rob

I would like to state my opinion on this matter, making it clear that I am o=
f the opinion that "GMP class should be final."

First of all, to meet the requirements that are the basis of this discussion=
, it is not actually necessary to expose the calculation logic; it is enough=
 to simply specify the class of result.

A practical approach to get around this issue is to tell php what class the r=
esult should be.

For example, could prepare a method like `resultClass(string $num1Class, str=
ing $num2Class, string $calcType): string|false`, and return the class name o=
f the result based on the class names of the two objects to be calculated an=
d the calculation type, such as addition or subtraction.

PHP calls this method as a "hook" when it finishes a calculation and returns=
 the result to determine the class of the return value.

But I don't like this because it's a "hacky" way of doing things with zend. A=
lso, I am concerned about the cost of doing this for every calculation.

The reason I'm putting together what I consider to be a bad method is becaus=
e it's possible that you or someone else will take my idea, add a twist that=
 I haven't thought of, and come up with a way to make it all work.

Regards,

Saki=