On Tue, Apr 2, 2024 at 5:43 PM Saki Takamachi <s...@sakiot.com> wrote:
> > 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. > Right, if a class is not final but has only final methods (including > constructor) and no protected properties then it allows people to extend it > but not break any encapsulation or (I think) impose any more BC > requirements on the maintainer (unless we care about conflicting with > method names of child classes when updating). It lets people just do > something a bit like adding 'extension methods' in C#. I like it. People > could write e.g. `$bcChildNumber->isPrime()` instead of > `BcNumberUtils::isPrime($bcNumber)` Yeah, I suspect the most common child class will be something like "Money" that additionally has a parameter denoting what currency the value is in, since that is by far the most common use case for arbitrary precision math in PHP. Making the calculation methods final should do fine in my opinion. > 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. > I think that having it be an optional part of the constructor and having a method to modify it is probably sufficient to help with operator overloads. Importantly, it still needs to take that setting and use it intelligently depending on the operation as we've discussed, but that should cover the use cases I was imagining. The exact behavior should be very clearly documented and explained though, as this is a different way of interacting with BCMath than the functions. It's better I think, because it takes advantage of the fact that this will be state-aware, which the functions aren't, and is one of the largest benefits of using objects. Also, to address an earlier question you had Saki, the term used should be "scale". Scale is the total number of digits to the right of the decimal point. Precision is the total number of significant digits. The BCMath C library works on scale, I believe, so that should carry over here. Most other arbitrary precision libraries in C use precision. Jordan
