Re: Overriding GMP objects

From: Date: Fri, 28 Jun 2024 00:43:26 +0000
Subject: Re: Overriding GMP objects
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-123981@lists.php.net to get a copy of this message
Hi Rob, >> On Thu, Jun 27, 2024, at 06:07, Saki Takamachi wrote: >> >> I agree with Gina. Being able to change the class of a computed result of an inherited >> child class causes several problems. >> >> The points raised in the BCMath\Number discussion can be >> summarized as follows. >> >> - If it is possible to perform calculations on parent Class and child Class, what should >> the resulting class be? > > Ask the class what it wants to be? > >> - Multiplying the distance class and the speed class should give you the time class. > > That would depend on the library’s implementation. > >> - Similarly, multiplying two distance classes together should yield an area class. > > See above. > >> - If only child classes have a property that should be specified in the constructor, how do >> you determine the value of this property in the result class? Perhaps it is possible to determine >> the value of the property, but in that case the commutativity of the computation should be lost. > > This can be handled via the child class in static methods, per the library specifications. > >> >> These problems cannot be solved without significant complexity. And there is a possibility >> that it cannot be resolved in the first place. > > I very much disagree; there is very little complications in the extension. It’s actually > quite simple: > > If one value is scalar and the other an instance of GMP, for binary ops, ask the GMP class to > perform the operation. (This is a one-linish change) > > If both are GMP instances, in a binary op, ask the left-most one to perform the op. The default > GMP implementation will delegate to the right-side if the right side isn’t a base-GMP instance, > otherwise, business as usual. > > And that’s pretty much it, other than defining the base-type ops. From there, you can > implement any units library you want, with whatever behavior makes sense — so long as the base > representation is a number. > > If I remember the original operator overloading RFC, this is exactly what was asked for by the > people who voted no. In theory, it should pass if brought as an RFC. > > — Rob I see. All of what I wrote are problems that arise when php doesn't provide a way to control them in userland. Your proposal implicitly allows operator overloading in userland. So your proposal essentially amounts to allowing operator overloading only for GMP classes. If I understand correctly, this discussion is not centered on GMP, but on the topic of limited exposure of operator overloading functionality. I believe this is something that requires some very careful discussion. Regards, Saki

« previous php.internals (#123981) next »