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
