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 WITHOUT it operating on objects
>>> themselves.
>>
>> 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 value, they merely represent the value.
>>
>> A GMP object instance that does not know its value? What are you even talking about? Can
>> you show me some code explaining what you mean? I had 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.
>
> 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.
>
> So, looking at your RFC and mine, I think this can be improved.
>
> What would you suggest it look like and then we can work backwards from there?
Here are my thoughts on your code.
In theory, inheriting from this "improved GMP class" would allow overloading of
computational operators.
In effect, this acts like a "calcable interface", with the constructor passing in
meaningless values to the parent constructor and the add method allowing the user to freely
modify the return value.
This means that virtually any userland class can use the operator overloading feature via a
"hack".
This approach is completely wrong. Rather than proposing this as is, it would be more constructive
to propose support for operator overloading.
Regards,
Saki