Re: [RFC] Operator Overrides -- Lite Edition

From: Date: Sun, 30 Jun 2024 07:31:03 +0000
Subject: Re: [RFC] Operator Overrides -- Lite Edition
References: 1  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
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.

>> 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?

Regards,

Saki


Thread (27 messages)

« previous php.internals (#124079) next »