Re: [RFC] Operator Overrides -- Lite Edition

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

« previous php.internals (#124084) next »