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 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
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.
--Larry Garfield