Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122920
Content-Type: text/plain;
	charset=us-ascii
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\))
Subject: Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath
In-Reply-To: <CAMrTa2EJf2NK2D3J=q7xkAVuNKsjEBDVv+RDmxp_g9DSsjRgwg@mail.gmail.com>
Date: Thu, 4 Apr 2024 11:31:08 +0900
Cc: Lynn <kjarli@gmail.com>,
 Aleksander Machniak <alec@alec.pl>,
 php internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <B1BFB481-B301-46BD-8E03-A418AA43EBB3@sakiot.com>
References: <4F094EDA-5058-407D-AF39-06FD934FDE1F@sakiot.com>
 <bbcff629-4dd6-bc50-ac9f-641849dc218a@php.net>
 <68CF373E-6ABF-4471-8992-813B4BA1B508@sakiot.com>
 <904197f4-afb5-401e-9e17-7a655c5449d0@alec.pl>
 <CAMrTa2EK6ymBQuxeFj7tMV0M2crqCCCR=mLN-FSfuCgrQHEZ6A@mail.gmail.com>
 <AB663F3F-A888-45F7-B19A-00530A4EDB0C@sakiot.com>
 <CAMrTa2HOEUWQcPdZE3FZ9JWCS1DWuRTNhhfqGGZOmr=v1Mctdw@mail.gmail.com>
 <CANS-=pfVuKKfAiu0LUJTrEPnSRaa_nHwJCgMvSORruAwHMsvQg@mail.gmail.com>
 <CAMrTa2HXD+62TKbaaA-v-mct5zdR5ortUAbtG1R1D22amAgpNA@mail.gmail.com>
 <CAMrTa2GaK3AUp0WodhNO8RdvoLbbiCk14Gs2oWF6vEs_+qMYNg@mail.gmail.com>
 <655FEA80-9AB4-4AAD-A310-70ED968C97A2@sakiot.com>
 <CAMrTa2Fh_-M_Kezi7s_4P4+a+dTyKq=RExd6ARPRDqZYS175kA@mail.gmail.com>
 <CAMrTa2FrkvNPK6kETNJFNNDn0mL5dxkV=PmdxsysruhhjY=Uig@mail.gmail.com>
 <8FB87901-02D7-4934-9119-55B21CEDDA9D@sakiot.com>
 <CAMrTa2EJf2NK2D3J=q7xkAVuNKsjEBDVv+RDmxp_g9DSsjRgwg@mail.gmail.com>
To: Jordan LeDoux <jordan.ledoux@gmail.com>
From: saki@sakiot.com (Saki Takamachi)

Hi Barney, Jordan,

> Right, if a class is not final but has only final methods (including =
constructor) and no protected properties then it allows people to extend =
it but not break any encapsulation or (I think) impose any more BC =
requirements on the maintainer (unless we care about conflicting with =
method names of child classes when updating). It lets people just do =
something a bit like adding 'extension methods' in C#. I like it. People =
could write e.g. `$bcChildNumber->isPrime()` instead of =
`BcNumberUtils::isPrime($bcNumber)`

> Yeah, I suspect the most common child class will be something like =
"Money" that additionally has a parameter denoting what currency the =
value is in, since that is by far the most common use case for arbitrary =
precision math in PHP. Making the calculation methods final should do =
fine in my opinion.

I realize that the purpose of using final here is to prevent users from =
customizing the behavior of operator overloads. In the RFC, there are =
methods that do not involve operator overloading, such as `round`, but =
do you think these should also be made final? Or should only methods =
related to overloading be made final?

IMHO, there are methods such as `powmod` that are computational =
functions but are not related to operator overloading, and from the =
viewpoint of consistency, we believe that all methods should be made =
final without exception.


> I think that having it be an optional part of the constructor and =
having a method to modify it is probably sufficient to help with =
operator overloads. Importantly, it still needs to take that setting and =
use it intelligently depending on the operation as we've discussed, but =
that should cover the use cases I was imagining.
>=20
> The exact behavior should be very clearly documented and explained =
though, as this is a different way of interacting with BCMath than the =
functions. It's better I think, because it takes advantage of the fact =
that this will be state-aware, which the functions aren't, and is one of =
the largest benefits of using objects.
>=20
> Also, to address an earlier question you had Saki, the term used =
should be "scale". Scale is the total number of digits to the right of =
the decimal point. Precision is the total number of significant digits. =
The BCMath C library works on scale, I believe, so that should carry =
over here. Most other arbitrary precision libraries in C use precision.

Thanks, I agree with you that it works a little differently than the =
existing BCMath function, so it needs to be well-documented.

I have summarized the discussion so far, made some corrections, and =
updated the RFC. I would be happy if you could check it out.

Regards.

Saki