On Tue, Apr 2, 2024 at 4:50 PM Saki Takamachi <s...@sakiot.com> wrote:
> > The two use cases at issue here are when the div and pow's exponent are > negative values. So how about allowing only these two methods to optionally > set `$scale` and `$roundMode` ? > > - The constructor takes only `$num` and always uses implicit scaling. > There is no option for the user to specify an arbitrary scale. > - `$scale`: If specified, use that value, otherwise use `10`. The scale > specified here is added to the scale of the left operand and used as the > scale of the result. In other words, `(new Number('0.01')->div('3', 2))` > results in `'0.0030' // scale = 2 + 2 = 4`. > - `$roundMode`: Specifies the rounding method when the result does not fit > within the scale. The initial value is `PHP_ROUND_TOWARD_ZERO`, which > matches the behavior of the BCMath function. That is, just truncate. > - If lucky enough to get the result within the scale, apply the implicit > scale to the result. In other words, if calculate `1 / 2`, the resulting > scale will be `1`, even if scale is `null` or specify a value such as `20` > for scale. > - The result of a calculation with operator overloading is the same as if > the option was not used when executing the method. > > However, I'm not sure if naming it `$scale` is appropriate. > > Also, since `BCMath\Number` is not made into a final class, there is a > possibility of implementing an inherited class in userland. Regarding this, > is it better to make the calculation method a final method, or to use a > function overridden by the user when executing from the opcode? > > 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. Jordan