On Sat, Jun 29, 2024, at 14:28, 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".
That is a very valid point, and I feel like it is something I definitely would have thought about
since I love abusing features to do things they shouldn't. My hope was that by removing the
ability to directly compare, it would reduce the usefulness of "hacking it" into generic
overloading since you have to return a GMP instance ... but then, I guess, that GMP instance
technically doesn't have to represent a number (though the rest of the engine will very much
treat it as a number).
I will think on this some more...
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 GMP class because right now, it is non-final. Then
I started thinking about Jordan's original proposal and how it could be simplified ...
there's certainly things to think about.
> This approach is completely wrong.
Ouch, I would hope it would have something useful to it. :)
>
> Rather than proposing this as is, it would be more constructive to propose support for operator
> overloading.
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.
— Rob