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
