Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123323
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\))
Subject: [PHP-DEV] [Discussion] Follow-up RFC for BCMath\Number object
Message-ID: <1D8D71FE-20DC-40E4-BEA5-4B438B8BC825@sakiot.com>
Date: Thu, 16 May 2024 22:53:26 +0900
Cc: "Gina P. Banyard" <internals@gpb.moe>,
 =?utf-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
To: php internals <internals@lists.php.net>
From: saki@sakiot.com (Saki Takamachi)

Hi all,

I would like to start additional discussion about BCMath\Number in this =
thread. If my summary is incorrect, please let me know.

First, make a list of points to note.=20



- Suggestions for using 64-bit integer types internally for performance

> If we are not going to use the newfound opaque type to introduce =
performance optimization for the common cases of small numbers that fit =
into 64-bit integers, then the value of adding a dedicated object is =
vastly diminished.
> Python is *literally* doing this sort of optimizations to improve the =
speed of their arbitrary precision integer type for the common use case =
of "small integers".
>=20
> In general, if it cannot fit in a native type then it should continue =
to use a string, but I would expect the *vast* majority of cases to fit =
in a 64-bit integer.

IMHO: I agree that it can be computed fairly quickly if the conditions =
are right. However, I believe that this itself does not require an RFC =
and can be addressed as part of a performance improvement.



- Points out regarding naming, such as changing "powmod" to =E2=80=9CpowMo=
d=E2=80=9D

IMHO: I simply copied the existing naming, so I have no objection to =
using the correct naming conventions.



- Points out regarding comparison methods

> In general, I am not sure why there is a need in the first place to =
expose any of the overloaded operators as methods.
> This includes the add/sub/div/mult/mod methods, but I can be convinced =
that this makes some sense.
>=20
> I was planning on tackling our rather broken comparison semantics [1] =
this year, but got distracted by the broken container/offset semantics =
instead. [2]
> As, IMHO, we need to fix the internal object handlers and semantics =
first before giving this power to userland.
> And I feel strongly that using instance methods for overload is the =
"wrong" way of doing it.
> Moreover, if we do provide the option for userland to overload they =
should, again IMHO, *just* be able to overload =3D=3D and <=3D>, not all =
the individual comparison operators.
> Thus, providing all those methods makes no sense to me.
>=20
> Moreover, taking inspiration from userland for naming methods because =
they *cannot* overload operators seems backwards.
> Userland classes, if they want to provide such functionality, *must* =
implement a wide range of methods, however an internal class does is not =
required to do this.
> Therefore, I am not really convinced by following suit on userland =
nomenclature.

IMHO: Indeed, as long as have compare, all the functions of the =
comparison method can be fulfilled. This is related to "Methods to be =
published" described later. These are exactly the I don't know if I'll =
use it, but I added it because it seemed useful'' method. Certainly, =
there are no things we can't do without these methods.

> However, I see no reason for exposing lt/gt/gte/lte.
> I am also not really a fan of the compare and equal methods to be =
instance methods compared to static methods.
> Adding those methods might interfere with any potential RFC that adds =
an Equatable/Ordable interface to allow userland classes to overload the =
comparison operators.

I think this is a type of functionality called =E2=80=9Cprocedural".



- Whether existing BCMath functions should accept BCMath\Number

IMHO: As Derick also mentioned, scale is handled differently, which can =
lead to confusion.



- About the behavior when casting BCMath\Number to bool

IMHO: I like it like int where 0 is false and everything else is true.



- Regarding whether the method you plan to publish is really necessary
Note: For example, the format() method only supports the notation =
methods of a limited number of countries, so its functionality is =
incomplete. In addition, it has been pointed out that it would be better =
not to expose many functions from the beginning, but to keep them to the =
minimum necessary first, and add some methods later.

IMHO: Admittedly, I may have crammed in too many features to make it =
useful. Which method do you think is the minimum required?



Regard,

Saki=