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

Hi Barney, Jordan, > 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. I realize that the purpose of using final here is to prevent users from customizing the behavior of operator overloads. In the RFC, there are methods that do not involve operator overloading, such as round, but do you think these should also be made final? Or should only methods related to overloading be made final? IMHO, there are methods such as powmod that are computational functions but are not related to operator overloading, and from the viewpoint of consistency, we believe that all methods should be made final without exception. > 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. Thanks, I agree with you that it works a little differently than the existing BCMath function, so it needs to be well-documented. I have summarized the discussion so far, made some corrections, and updated the RFC. I would be happy if you could check it out. Regards. Saki