Hi, >> 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
I would like to state my opinion on this matter, making it clear that I am of the opinion that "GMP class should be final." First of all, to meet the requirements that are the basis of this discussion, it is not actually necessary to expose the calculation logic; it is enough to simply specify the class of result. A practical approach to get around this issue is to tell php what class the result should be. For example, could prepare a method like `resultClass(string $num1Class, string $num2Class, string $calcType): string|false`, and return the class name of the result based on the class names of the two objects to be calculated and the calculation type, such as addition or subtraction. PHP calls this method as a "hook" when it finishes a calculation and returns the result to determine the class of the return value. But I don't like this because it's a "hacky" way of doing things with zend. Also, I am concerned about the cost of doing this for every calculation. The reason I'm putting together what I consider to be a bad method is because it's possible that you or someone else will take my idea, add a twist that I haven't thought of, and come up with a way to make it all work. Regards, Saki
