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