Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123923
Content-Type: text/plain;
	charset=utf-8
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\))
Subject: Re: [PHP-DEV] [Discussion] Follow-up RFC for BCMath\Number object
In-Reply-To: <jM5XWx-f-SLDglJV4x2HcvqQkzHrZSyGrPlYHcvKqF8jyIiA_3ccMl3W9vJxjFnt4wqm71XL3FGdP1dZcKlWkJl_AgGz6o0PKrxgkreYwy4=@gpb.moe>
Date: Thu, 27 Jun 2024 14:00:45 +0900
Cc: php internals <internals@lists.php.net>,
 =?utf-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Content-Transfer-Encoding: quoted-printable
Message-ID: <34B36893-DB63-494B-AAAF-E3756F7F9787@sakiot.com>
References: <1D8D71FE-20DC-40E4-BEA5-4B438B8BC825@sakiot.com>
 <D0460A50-65E2-44C8-B535-FD2929229049@sakiot.com>
 <jM5XWx-f-SLDglJV4x2HcvqQkzHrZSyGrPlYHcvKqF8jyIiA_3ccMl3W9vJxjFnt4wqm71XL3FGdP1dZcKlWkJl_AgGz6o0PKrxgkreYwy4=@gpb.moe>
To: "Gina P. Banyard" <internals@gpb.moe>
From: saki@sakiot.com (Saki Takamachi)

Hi Gina,

> Apologies for the delay, to much traffic on the list so I forgot to =
address this.

Don=E2=80=99t worry!


>=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.
>=20
>=20
> ACK, this seems to be fine.
>=20
>=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.
>=20
>=20
> ACK, this seems to be fine.
>=20
>=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 the property. In some cases, we may consider adding it again, but =
at least not in 8.4. This also requires an RFC.
>>=20
>=20
> Seems sensible to me.

OK, thanks!



>>> - 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 follow that naming, "powmod" is not unnatural. Since "bcpowmod" =
already exists, 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 only one comparison method. This requires an override RFC.
>=20
> I'm grouping those points together.
> My main concern with adding those methods to the class is that this =
will potentially conflict with any implementation of operator and/or =
comparison overloading.
> This is why I would rather not have the methods at all, if the idea is =
to have a "procedural" API I feel revisiting Andrea's old "Operator =
functions" RFC would be better.
> https://wiki.php.net/rfc/operator_functions

First of all, am I correct in understanding that there is no problem =
with the naming of "powmod=E2=80=9D?

Also, given that I have implemented only one "compare()" method, how =
could this conflict with them? Number is a final class, so there is no =
room for the user to change its behavior.


>>> - 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 =
true. 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.
>=20
> I think this is the most sensible, in which case I think GMP should =
also follow suit and have the same semantics instead of currently being =
broken when you try to cast to bool.

That makes sense. However, I would like to have a separate vote on GMP =
changes. For procedural efficiency, we will combine them into one RFC, =
but each will be voted on separately, and each requires a 2/3 or more =
vote in favor. In other words, two primary votes will be held at the =
same time.

Regards,

Saki