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

Hi Tim, > 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. > } Ah I see. I misunderstood. I will add it when the discussion is settled. >>> - 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. Thanks! >>> - 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 What I meant was that there is currently no such function in PHP. Do you think I should propose adding it to this RFC? >>> - 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. I agree, but if we adopt Rowan's suggestion this issue will go away, so if the issue is still there when things calm down I'll add the error. Regards. Saki