Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123921
Date: Thu, 27 Jun 2024 04:21:35 +0000
To: Saki Takamachi <saki@sakiot.com>
Cc: php internals <internals@lists.php.net>, =?utf-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Subject: Re: [PHP-DEV] [Discussion] Follow-up RFC for BCMath\Number object
Message-ID: <jM5XWx-f-SLDglJV4x2HcvqQkzHrZSyGrPlYHcvKqF8jyIiA_3ccMl3W9vJxjFnt4wqm71XL3FGdP1dZcKlWkJl_AgGz6o0PKrxgkreYwy4=@gpb.moe>
In-Reply-To: <D0460A50-65E2-44C8-B535-FD2929229049@sakiot.com>
References: <1D8D71FE-20DC-40E4-BEA5-4B438B8BC825@sakiot.com> <D0460A50-65E2-44C8-B535-FD2929229049@sakiot.com>
Feedback-ID: 96993444:user:proton
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: internals@gpb.moe ("Gina P. Banyard")


On Tuesday, 25 June 2024 at 17:58, Saki Takamachi <saki@sakiot.com> wrote:

> Hi!
>=20
> This is a reminder as the feature freeze is approaching. I would like to =
restate my current opinion.

Apologies for the delay, to much traffic on the list so I forgot to address=
 this.


>=20
> > - Suggestions for using 64-bit integer types internally for performance
>=20
>=20
> This is probably unnecessary. It's already fast enough, so it might be a =
good idea to consider it when we need even more speed. Also, if we want to =
speed things up even more, it would probably be better to change the design=
 of the bc_num structure.


ACK, this seems to be fine.

>=20
> > - Points out regarding naming, such as changing "powmod" to =E2=80=
=9CpowMod=E2=80=9D
>=20
>=20
> A function called "divmod" is also commonly used in other languages. If f=
ollow that naming, "powmod" is not unnatural. Since "bcpowmod" already exis=
ts, I feel that it is okay to leave it as "powmod=E2=80=9D.
>=20
> > - Points out regarding comparison methods
>=20
>=20
> For now, all comparisons are possible with just "compare", so I'll use on=
ly one comparison method. This requires an override RFC.

I'm grouping those points together.
My main concern with adding those methods to the class is that this will po=
tentially conflict with any implementation of operator and/or comparison ov=
erloading.
This is why I would rather not have the methods at all, if the idea is to h=
ave a "procedural" API I feel revisiting Andrea's old "Operator functions" =
RFC would be better.
https://wiki.php.net/rfc/operator_functions

>=20
> > - Whether existing BCMath functions should accept BCMath\Number
>=20
>=20
> At least not in 8.4. I don't think any ideas for how to use scale properl=
y will be finalized before the feature freezes.

ACK, the context is also different than for ext/gmp which I misremembered.

>=20
> > - About the behavior when casting BCMath\Number to bool
>=20
>=20
> If the value is 0, it is treated as false, otherwise it is treated as tru=
e. This alone may not require an RFC, but I'm planning to create an RFC for=
 the comparison method, so I'll include it there.

I think this is the most sensible, in which case I think GMP should also fo=
llow suit and have the same semantics instead of currently being broken whe=
n you try to cast to bool.

>=20
> > - Regarding whether the method you plan to publish is really necessary
>=20
> I decide to delete the format method. We can cast or get the value from t=
he property. In some cases, we may consider adding it again, but at least n=
ot in 8.4. This also requires an RFC.
>=20

Seems sensible to me.


Best regards,

Gina P. Banyard