Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122918
Precedence: bulk
MIME-Version: 1.0
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>
In-Reply-To: <8FB87901-02D7-4934-9119-55B21CEDDA9D@sakiot.com>
Date: Wed, 3 Apr 2024 17:54:19 -0700
Message-ID: <CAMrTa2EJf2NK2D3J=q7xkAVuNKsjEBDVv+RDmxp_g9DSsjRgwg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath
To: Saki Takamachi <saki@sakiot.com>
Cc: Lynn <kjarli@gmail.com>, Aleksander Machniak <alec@alec.pl>, 
	php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000004ae01906153ac82b"
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--0000000000004ae01906153ac82b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Apr 2, 2024 at 5:43=E2=80=AFPM Saki Takamachi <saki@sakiot.com> wro=
te:

>
> If make a class final, users will not be able to add arbitrary methods, s=
o
> 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.
>


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.


> 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 an=
y
> 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.
>

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.

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.

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.

Jordan

--0000000000004ae01906153ac82b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Tue, Apr 2, 2024 at 5:43=E2=80=AFP=
M Saki Takamachi &lt;<a href=3D"mailto:saki@sakiot.com">saki@sakiot.com</a>=
&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
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 sep=
arate behavior between method and opcode calculations, this is inconsistent=
 and confusing to users and should be avoided.<br></blockquote><div>=C2=A0<=
/div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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
      &#39;extension methods&#39; in C#. I like it. People could write e.g.
      `$bcChildNumber-&gt;isPrime()` instead of `BcNumberUtils::isPrime($bc=
Number)`</blockquote><div><br></div><div>Yeah, I suspect the most common ch=
ild class will be something like &quot;Money&quot; 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 calcul=
ation methods final should do fine in my opinion.<br></div><div>=C2=A0<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex">
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 sc=
ale when calculating with opcodes. If we want to specify a different scale =
for each calculation, you can do it using methods.<br>
Or would it be more convenient to have a method to reset `$scale` and `$rou=
ndMode`? It is immutable, so when reset it returns a new instance.<br></blo=
ckquote><div><br></div><div>I think that having it be an optional part of t=
he constructor and having a method to modify it is probably sufficient to h=
elp with operator overloads. Importantly, it still needs to take that setti=
ng and use it intelligently depending on the operation as we&#39;ve discuss=
ed, but that should cover the use cases I was imagining.</div><div><br></di=
v><div>The exact behavior should be very clearly documented and explained t=
hough, as this is a different way of interacting with BCMath than the funct=
ions. It&#39;s better I think, because it takes advantage of the fact that =
this will be state-aware, which the functions aren&#39;t, and is one of the=
 largest benefits of using objects.</div><div><br></div><div>Also, to addre=
ss an earlier question you had Saki, the term used should be &quot;scale&qu=
ot;. 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 arbit=
rary precision libraries in C use precision.<br></div><div><br></div><div>J=
ordan <br></div></div></div>

--0000000000004ae01906153ac82b--