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
