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
