Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122903
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>
In-Reply-To: <655FEA80-9AB4-4AAD-A310-70ED968C97A2@sakiot.com>
Date: Tue, 2 Apr 2024 17:05:30 -0700
Message-ID: <CAMrTa2Fh_-M_Kezi7s_4P4+a+dTyKq=RExd6ARPRDqZYS175kA@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="000000000000f8628e061525fb4f"
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--000000000000f8628e061525fb4f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Apr 2, 2024 at 4:50=E2=80=AFPM Saki Takamachi <saki@sakiot.com> wro=
te:

>
> The two use cases at issue here are when the div and pow's exponent are
> negative values. So how about allowing only these two methods to optional=
ly
> set `$scale` and `$roundMode` ?
>
> - The constructor takes only `$num` and always uses implicit scaling.
> There is no option for the user to specify an arbitrary scale.
> - `$scale`: If specified, use that value, otherwise use `10`. The scale
> specified here is added to the scale of the left operand and used as the
> scale of the result. In other words, `(new Number('0.01')->div('3', 2))`
> results in `'0.0030' // scale =3D 2 + 2 =3D 4`.
> - `$roundMode`: Specifies the rounding method when the result does not fi=
t
> within the scale. The initial value is `PHP_ROUND_TOWARD_ZERO`, which
> matches the behavior of the BCMath function. That is, just truncate.
> - If lucky enough to get the result within the scale, apply the implicit
> scale to the result. In other words, if calculate `1 / 2`, the resulting
> scale will be `1`, even if scale is `null` or specify a value such as `20=
`
> for scale.
> - The result of a calculation with operator overloading is the same as if
> the option was not used when executing the method.
>
> However, I'm not sure if naming it `$scale` is appropriate.
>
> Also, since `BCMath\Number` is not made into a final class, there is a
> possibility of implementing an inherited class in userland. Regarding thi=
s,
> is it better to make the calculation method a final method, or to use a
> function overridden by the user when executing from the opcode?
>
>
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.

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.

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.

Jordan

--000000000000f8628e061525fb4f
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 4:50=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>
The two use cases at issue here are when the div and pow&#39;s exponent are=
 negative values. So how about allowing only these two methods to optionall=
y set `$scale` and `$roundMode` ?<br>
<br>
- The constructor takes only `$num` and always uses implicit scaling. There=
 is no option for the user to specify an arbitrary scale.<br>
- `$scale`: If specified, use that value, otherwise use `10`. The scale spe=
cified here is added to the scale of the left operand and used as the scale=
 of the result. In other words, `(new Number(&#39;0.01&#39;)-&gt;div(&#39;3=
&#39;, 2))` results in `&#39;0.0030&#39; // scale =3D 2 + 2 =3D 4`.<br>
- `$roundMode`: Specifies the rounding method when the result does not fit =
within the scale. The initial value is `PHP_ROUND_TOWARD_ZERO`, which match=
es the behavior of the BCMath function. That is, just truncate.<br>
- If lucky enough to get the result within the scale, apply the implicit sc=
ale to the result. In other words, if calculate `1 / 2`, the resulting scal=
e will be `1`, even if scale is `null` or specify a value such as `20` for =
scale.<br>
- The result of a calculation with operator overloading is the same as if t=
he option was not used when executing the method.<br>
<br>
However, I&#39;m not sure if naming it `$scale` is appropriate.<br>
<br>
Also, since `BCMath\Number` is not made into a final class, there is a poss=
ibility of implementing an inherited class in userland. Regarding this, is =
it better to make the calculation method a final method, or to use a functi=
on overridden by the user when executing from the opcode?<br>
<br></blockquote><div><br></div><div>The issue is that, presumably, this me=
thod will be used within the operator overload portion of the class entry i=
n 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 argument=
s 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 u=
serland. I very much like the feature, but I also think it should be intent=
ionally 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.</div>=
<div><br></div><div>And operator overloads are also the place where what yo=
u outlined above gets murky. I think what you outlined is very close to a g=
ood final design for just the method usage side, but the operator usage sid=
e CANNOT provide a scale or a rounding mode. That should be taken into cons=
ideration, because allowing this object to be used with operators is probab=
ly the single largest benefit this RFC will provide to PHP developers.</div=
><div><br></div><div>What I ended up doing was that the VALUE of the object=
 was immutable, but the other information was not immutable. That has its o=
wn downsides, but does allow for very explicit control from the developer a=
t the section of code using the class, but also avoids creating copies of t=
he object or instantiating a new object for every single &quot;setting&quot=
; change during calculations.<br></div><div><br></div><div>Jordan <br></div=
></div></div>

--000000000000f8628e061525fb4f--