Re: [RFC] Operator Overrides -- Lite Edition

On Sun, Jun 30, 2024, at 13:37, Saki Takamachi wrote: > > 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 Thanks, I would love to address your issues but you’ve given me nothing actionable to work with. Thank you for your time. — Rob