Re: [RFC] Operator Overrides -- Lite Edition

On Sun, Jun 30, 2024, at 09:31, Saki Takamachi wrote: > Hi, > > >> It seems like the "hack" I mentioned is still possible, am I > >> misunderstanding something? > > > > That’s always going to be a possibility, no matter what we do or how we do it. I think > > it would be a rather pointless hack now that I can run the code. For the most part, the engine > > treats these as numbers and trying to dodge that will land you in hot water eventually. > > 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. > > >> And I don't understand the purpose of polyfills at all. If you're not using > >> the GMP extensions and can't do operator overloading, won't you just have a class with > >> protected methods that are never used and don't actually do anything? > > > > Ah, that could probably be clearer in the RFC, but you have to make it public to be able > > to use it. > > > > It’s a bit clunky to use without the extension, but that’s mostly because I didn’t > > want to get into OperandPosition from Jordan’s RFC. Many people were confused about it, so I’m > > just avoiding it. > > 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! — Rob