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

On Tue, Apr 2, 2024 at 5:05 PM Jordan LeDoux <jordan.ledoux@gmail.com> wrote: > > > On Tue, Apr 2, 2024 at 4:50 PM Saki Takamachi <saki@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 > 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. Jordan