Hi, >> I'm not sure. Does this mean that such "hack" is unavoidable? >> >> And I don't really understand what "pointless hack" means. This would make >> sense if operator overloading was already allowed, but it isn't. > > Not unavoidable, but pointless. For example, I attempted to create a String > class that used + for concatenation. This kinda works, but if you pass it to > something that takes a string, you get the underlying number and not the > string you were trying to store. This is because GMP takes over casting > forcing you to stick to numerical constructs.
I don't understand why you only consider the casting case. You can simply convert it to a string via a method. As long as don't use any casting at the end, users can implement it however they like. I don't think this is a pointless hack. Also, allowing "hack" just because they're not useful is not a good idea. Again, if such functionality is provided, it should be exposed as formal support for operator overloading. >> This is very confusing me. Why does this need to be a child class of GMP? > > This is addressed in the current RFC text, if I missed something, please ask! I don't understand why the GMP RFC mentions environments where GMP is not used. There are a few other points worth mentioning, but the existence of polyfills makes this especially confusing. > To be usable, the developer must override the desired operations and make > them public Is this referring to a polyfill? Or is this just a necessary step to override the overload? Regards, Saki
