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
