Hi Jordan, > The issue is that, presumably, this method will be used within the operator > overload portion of the class entry in C. If it is allowed to be overridden, > then this RFC is sort of providing a stealth operator overload to PHP > developers. As much as I am for operator overloads having written an RFC for > it, and as much as I find the arguments generally against it lacking, I am > not in favor of doing it that way with a kind of... unspoken capability to > overload the basic math operators in userland. I very much like the feature, > but I also think it should be intentionally and specifically designed, which > is why I spent a long time on it. I do not get a vote for RFCs, but I would > vote against this if I could just for that reason IF the calculation methods > were not private, the class was not final, AND the function entry was used in > the operator overload. > > And operator overloads are also the place where what you outlined above gets > murky. I think what you outlined is very close to a good final design for > just the method usage side, but the operator usage side CANNOT provide a > scale or a rounding mode. That should be taken into consideration, because > allowing this object to be used with operators is probably the single largest > benefit this RFC will provide to PHP developers. > > What I ended up doing was that the VALUE of the object was immutable, but the > other information was not immutable. That has its own downsides, but does > allow for very explicit control from the developer at the section of code > using the class, but also avoids creating copies of the object or > instantiating a new object for every single "setting" change during > calculations.
Agree. I also have negative thoughts about this, but I wanted to hear everyone's opinions, so I sent the email I mentioned earlier. If make a class final, users will not be able to add arbitrary methods, so I think making each method final. Although it is possible to completely separate behavior between method and opcode calculations, this is inconsistent and confusing to users and should be avoided. > I should clarify, the portion of your outline that I feel is not sufficient > for the operator overload use case is that there is no way to use both > operator overloads AND a scale other than 10 + left operand scale. How about setting the `$scale` and `$roundMode` that I mentioned earlier in the constructor instead of `div` and `pow`? By doing so, we can use any scale when calculating with opcodes. If we want to specify a different scale for each calculation, you can do it using methods. Or would it be more convenient to have a method to reset `$scale` and `$roundMode`? It is immutable, so when reset it returns a new instance. Regards. Saki
