Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122904
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>
In-Reply-To: <CAMrTa2Fh_-M_Kezi7s_4P4+a+dTyKq=RExd6ARPRDqZYS175kA@mail.gmail.com>
Date: Tue, 2 Apr 2024 17:16:30 -0700
Message-ID: <CAMrTa2FrkvNPK6kETNJFNNDn0mL5dxkV=PmdxsysruhhjY=Uig@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="0000000000003e415706152623c2"
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--0000000000003e415706152623c2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Apr 2, 2024 at 5:05=E2=80=AFPM Jordan LeDoux <jordan.ledoux@gmail.c=
om>
wrote:

>
>
> On Tue, Apr 2, 2024 at 4:50=E2=80=AFPM Saki Takamachi <saki@sakiot.com> w=
rote:
>
>>
>> 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 optiona=
lly
>> 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
>> fit within the scale. The initial value is `PHP_ROUND_TOWARD_ZERO`, whic=
h
>> 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 `2=
0`
>> for scale.
>> - The result of a calculation with operator overloading is the same as i=
f
>> 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 th=
is,
>> 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 overloa=
d
> 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... unspoke=
n
> 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 g=
et
> 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 desig=
n
> for just the method usage side, but the operator usage side CANNOT provid=
e
> 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
>

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.

Jordan

--0000000000003e415706152623c2
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:05=E2=80=AFP=
M Jordan LeDoux &lt;<a href=3D"mailto:jordan.ledoux@gmail.com">jordan.ledou=
x@gmail.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"><div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gm=
ail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Apr 2, 2024 at 4:5=
0=E2=80=AFPM Saki Takamachi &lt;<a href=3D"mailto:saki@sakiot.com" target=
=3D"_blank">saki@sakiot.com</a>&gt; wrote:<br></div><blockquote class=3D"gm=
ail_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></blockquote><div><br></div><div>I should clarify, the portion=
 of your outline that I feel is not sufficient for the operator overload us=
e case is that there is no way to use both operator overloads AND a scale o=
ther than 10=C2=A0+ left operand scale.</div><div><br></div><div>Jordan<br>=
</div></div></div>

--0000000000003e415706152623c2--