Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123828
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: <1D8D71FE-20DC-40E4-BEA5-4B438B8BC825@sakiot.com>
Date: Wed, 26 Jun 2024 01:58:03 +0900
Cc: "Gina P. Banyard" <internals@gpb.moe>,
 =?utf-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Content-Transfer-Encoding: quoted-printable
Message-ID: <D0460A50-65E2-44C8-B535-FD2929229049@sakiot.com>
References: <1D8D71FE-20DC-40E4-BEA5-4B438B8BC825@sakiot.com>
To: php internals <internals@lists.php.net>
From: saki@sakiot.com (Saki Takamachi)

Hi!

This is a reminder as the feature freeze is approaching. I would like to =
restate my current opinion.

> - Suggestions for using 64-bit integer types internally for =
performance

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.

> - Points out regarding naming, such as changing "powmod" to =
=E2=80=9CpowMod=E2=80=9D

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.

> - Points out regarding comparison methods

For now, all comparisons are possible with just "compare", so I'll use =
only one comparison method. This requires an override RFC.

> - Whether existing BCMath functions should accept BCMath\Number

At least not in 8.4. I don't think any ideas for how to use scale =
properly will be finalized before the feature freezes.

> - About the behavior when casting BCMath\Number to bool

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.

> - Regarding whether the method you plan to publish is really necessary
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.

Regards,

Saki=