Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122905
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: <CAMrTa2FrkvNPK6kETNJFNNDn0mL5dxkV=PmdxsysruhhjY=Uig@mail.gmail.com>
Date: Wed, 3 Apr 2024 09:42:50 +0900
Cc: Lynn <kjarli@gmail.com>,
 Aleksander Machniak <alec@alec.pl>,
 php internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <8FB87901-02D7-4934-9119-55B21CEDDA9D@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>
To: Jordan LeDoux <jordan.ledoux@gmail.com>
From: saki@sakiot.com (Saki Takamachi)

Hi Jordan,

> The issue is that, presumably, this method will be used within the =
operator overload portion of the class entry in C. If it is allowed to =
be overridden, then this RFC is sort of providing a stealth operator =
overload to PHP developers. As much as I am for operator overloads =
having written an RFC for it, and as much as I find the arguments =
generally against it lacking, I am not in favor of doing it that way =
with a kind of... unspoken capability to overload the basic math =
operators in userland. I very much like the feature, but I also think it =
should be intentionally and specifically designed, which is why I spent =
a long time on it. I do not get a vote for RFCs, but I would vote =
against this if I could just for that reason IF the calculation methods =
were not private, the class was not final, AND the function entry was =
used in the operator overload.
>=20
> And operator overloads are also the place where what you outlined =
above gets murky. I think what you outlined is very close to a good =
final design for just the method usage side, but the operator usage side =
CANNOT provide a scale or a rounding mode. That should be taken into =
consideration, because allowing this object to be used with operators is =
probably the single largest benefit this RFC will provide to PHP =
developers.
>=20
> What I ended up doing was that the VALUE of the object was immutable, =
but the other information was not immutable. That has its own downsides, =
but does allow for very explicit control from the developer at the =
section of code using the class, but also avoids creating copies of the =
object or instantiating a new object for every single "setting" change =
during calculations.

Agree. I also have negative thoughts about this, but I wanted to hear =
everyone's opinions, so I sent the email I mentioned earlier.

If make a class final, users will not be able to add arbitrary methods, =
so I think making each method final. Although it is possible to =
completely separate behavior between method and opcode calculations, =
this is inconsistent and confusing to users and should be avoided.

> I should clarify, the portion of your outline that I feel is not =
sufficient for the operator overload use case is that there is no way to =
use both operator overloads AND a scale other than 10 + left operand =
scale.


How about setting the `$scale` and `$roundMode` that I mentioned earlier =
in the constructor instead of `div` and `pow`? By doing so, we can use =
any scale when calculating with opcodes. If we want to specify a =
different scale for each calculation, you can do it using methods.
Or would it be more convenient to have a method to reset `$scale` and =
`$roundMode`? It is immutable, so when reset it returns a new instance.

Regards.

Saki=