Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123076
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Mime-Version: 1.0 (1.0)
Subject: Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath
Date: Wed, 10 Apr 2024 08:26:54 +0900
Message-ID: <9A85CC53-EFDB-4D14-99FB-ACFA4C6DBD09@sakiot.com>
References: <cb6bb26f-8db1-4a9a-851a-bc6ed7c43bfd@bastelstu.be>
Cc: internals@lists.php.net
In-Reply-To: <cb6bb26f-8db1-4a9a-851a-bc6ed7c43bfd@bastelstu.be>
To: =?utf-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
From: saki@sakiot.com (Saki Takamachi)

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, pro=
perties, and methods. It's currently split across multiple code blocks and t=
he interfaces are missing entirely.
>=20
> Example:
>=20
>    final readonly class Number implements \Stringable {
>        public string $value;
>        // Further properties omitted for brevity.
>=20
>        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, b=
ut for the rounding mode, I wonder if we should first add the RoundingMode e=
num 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::$ro=
undMode` 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 discussi=
on. I'd be happy to co-author it.
>> Oh, that's a good idea. Makes sense. I think it would be simpler to prepa=
re an RFC separate from this RFC, so I'm going to create one right away. Onc=
e you have a certain amount of content, I would be happy if you could check i=
t out and make corrections if necessary.
>=20
> Sure, just send me an email and I'm happy to look over it before you put i=
t up for discussion.

Thanks!


>>> - For `format()`, I'm not sure whether we should actually add the functi=
on. While we have number_format() for regular numbers with the same signatur=
e, 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 i=
n 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 strin=
g type number without converting it to a float?
>=20
> It appears the underlying icu4c library supports formatting numeric string=
s, yes:
>=20
> https://unicode-org.github.io/icu-docs/apidoc/dev/icu4c/classicu_1_1Number=
Format.html#a8ed2ca7b9a65bf08c4ef81bbf9680f0d

What I meant was that there is currently no such function in PHP. Do you thi=
nk I should propose adding it to this RFC?


>>> - I'm not sure if the priority for the rounding modes is sound. My gut f=
eeling 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 w=
rong here.
>> As mentioned in the RFC, the problem here is commutative calculations (ad=
d, sub, mul). This means that even if specify `$roundingMode` during these c=
alculations, `$roundingMode` will not be used in these calculations. Calcula=
tions that use `$roundingMode` are divs, etc. If allow `$roundingMode` to be=
 specified with add, intuitively it feels like the result of add will be rou=
nded.
>> Also, it is not possible to specify `$roundMode` in calculations using op=
erators.
>> 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 r=
esult the user would want to get. Therefore, it may be better to make this a=
n error.
>> Is it appropriate to throw a value error in that case?
>=20
> I think making this an error would be appropriate. Generally speaking: Rem=
oving errors later is always possible if we find out that an operation is sa=
fe and well-defined. Adding an error if we find out that an operation is uns=
afe will result in breaking changes, thus we should get it right on the firs=
t try.

I agree, but if we adopt Rowan's suggestion this issue will go away, so if t=
he issue is still there when things calm down I'll add the error.

Regards.

Saki=