Re: [RFC] [Discussion] Support object type in BCMath

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