Re: [RFC] Operator Overrides -- Lite Edition

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