Hi, >> On Sun, Jun 30, 2024, at 13:05, Saki Takamachi wrote: >> >> 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. > > We could just delete php-src, grab a beer, and watch the sunset. I don’t > think you’ll ever be able to stop some programmers from hacking things > together to solve business problems though. I’ve “hacked” weakmaps in > userland to make Hour(1) === (yes, there are three! Equals there) Minute(60). > >> >> Again, if such functionality is provided, it should be exposed as formal >> support for operator overloading. > > Thank you for your opinion, this RFC doesn’t stop that from happening and is > completely orthogonal. > >> >>>> 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? > > I recommend reading up on what a polyfill is, and why they are useful, if you > are confused. But to answer your question, no, it has nothing to do with the > polyfill, it’s just a necessary step. The polyfill is just provided for > completeness. > >> >> Regards, >> >> Saki > > — Rob
I understand your point, and any further comment from me would probably be of little value to you. This will be my last post on this thread. I will definitely vote against this RFC unless the issues I have pointed out are addressed. No matter how innocuous they may seem, I would rather not expose operator overloading in the form of such "hack". Regards, Saki
