Re: [RFC] Operator Overrides -- Lite Edition

From: Date: Sun, 30 Jun 2024 11:05:02 +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,

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


Thread (27 messages)

« previous php.internals (#124082) next »