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

Hi On 4/8/24 02:08, Saki Takamachi wrote:

- The full “stub” should probably include an explicit "implements Stringable" for clarity.

Agree. I describe it explicitly during implementation.

I don't see a change made, so perhaps I was unclear in what I said. What I meant was: Please add a full stub example including all the interfaces, properties, and methods. It's currently split across multiple code blocks and the interfaces are missing entirely. Example:

    final readonly class Number implements \Stringable {
        public string $value;
        // Further properties omitted for brevity.

        public function add(Number|string|int $num): Number {}
        // Further methods omitted for brevity.
    }

- I don't want to expand the scope of your RFC further than necessary, but for the rounding mode, I wonder if we should first add the RoundingMode enum that has been suggested during the discussion of the "Add 4 new rounding modes to round() function" RFC. It would make the type for the Number::$roundMode property much clearer than the current int. I expect the addition of such an enum to be a pretty simple RFC that would not need much discussion. I'd be happy to co-author it.

Oh, that's a good idea. Makes sense. I think it would be simpler to prepare an RFC separate from this RFC, so I'm going to create one right away. Once you have a certain amount of content, I would be happy if you could check it out and make corrections if necessary.

Sure, just send me an email and I'm happy to look over it before you put it up for discussion.

- For format(), I'm not sure whether we should actually add the function. While we have number_format() for regular numbers with the same signature, it fails to account for the different language and cultures in the world. Specifically number_format() cannot correctly format numbers for en_IN (i.e. English in India). In India numbers are not separated every three digits, but rather the three right-most digits and then every two digits. Here's in example: 1,23,45,67,890. I believe formatting should be best left for ext/intl.

I'm not very familiar with ext/intl, but is there a way to format a string type number without converting it to a float?

It appears the underlying icu4c library supports formatting numeric strings, yes: https://unicode-org.github.io/icu-docs/apidoc/dev/icu4c/classicu_1_1NumberFormat.html#a8ed2ca7b9a65bf08c4ef81bbf9680f0d

- I'm not sure if the priority for the rounding modes is sound. My gut feeling is that operations on numbers with different rounding modes should be disallowed or made explicit during the operation (much like the scale for a division), but I'm not an expert in designing numeric APIs, so I might be wrong here.

As mentioned in the RFC, the problem here is commutative calculations (add, sub, mul). This means that even if specify $roundingMode during these calculations, $roundingMode will not be used in these calculations. Calculations that use $roundingMode are divs, etc. If allow $roundingMode to be specified with add, intuitively it feels like the result of add will be rounded. Also, it is not possible to specify $roundMode in calculations using operators. However, if the user calculates two numbers with different rounding modes, and it is intentional rather than a mistake, I can't imagine what kind of result the user would want to get. Therefore, it may be better to make this an error. Is it appropriate to throw a value error in that case?

I think making this an error would be appropriate. Generally speaking: Removing errors later is always possible if we find out that an operation is safe and well-defined. Adding an error if we find out that an operation is unsafe will result in breaking changes, thus we should get it right on the first try. Best regards Tim Düsterhus