Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123241
Precedence: bulk
MIME-Version: 1.0
References: <18c42fdbb30.2831.17a3710df6d58f02ca570cc47e197a63@interi.co>
 <0f64523d-d949-75ed-682b-789fc33fa3b2@php.net> <CAOyH9yRfFBKis_eoMp=V_Y8+03yrqg=rMtJMbd+ifeJUwkGczw@mail.gmail.com>
 <CAOyH9ySpRv9uTj5+p7JzE=j1f49gO6N4W73NYSse7Ax1VYjd3Q@mail.gmail.com>
 <AD712363-98FA-4B95-BBD1-30B2B0CD2BE5@rwec.co.uk> <CAPzBOBP5rCixsk8kzrvfeFwBL7Yio0KLKF2bhCSthsN=h6+iBA@mail.gmail.com>
 <DDF09CB6-70AD-4668-BAD4-312ACA427B05@rwec.co.uk>
In-Reply-To: <DDF09CB6-70AD-4668-BAD4-312ACA427B05@rwec.co.uk>
Date: Tue, 30 Apr 2024 21:16:20 +0300
Message-ID: <CAL0xaBGsJNakjSfd1nUmsx07J5Oi_53X02nZkKEnFheF8ogaoA@mail.gmail.com>
Subject: Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000001b9af106175460af"
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--0000000000001b9af106175460af
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 30 Apr 2024 at 09:19, Rowan Tommins [IMSoP] <imsop.php@rwec.co.uk>
wrote:

>
>
> On 28 April 2024 07:47:40 GMT-07:00, Robert Landers <
> landers.robert@gmail.com> wrote:
>
> >I'm not so sure this could be implemented as an extension, there just
> >isn't the right hooks for it.
>
> The whole point of my email was that "this" is not one single feature, bu=
t
> a whole series of them. Some of them can be implemented as an extension
> right now; some could be implemented as an extension by adding more hooks
> which would also be useful for other extensions; some would need changes =
to
> the core of the language.
>
> If the aim is "everything you could possibly want in a decimal type", it
> certainly can't be an extension; if the aim is "better support for
> decimals", then it possibly can.
>
> Regards,
> Rowan Tommins
> [IMSoP]
>

I think setting some expectations in the proper context is warranted here.

1. Would a native decimal type be good for the language? I would say we
probably are not going to find many if any people who would be against it.
2. Is there a need for it? Well, the whole world of e-commerce, accounting
and all kinds of business systems that deal with money in PHP world do not
leave any room for doubt - https://packagist.org/?query=3Dmoney . The use
case is right there :)
3. In most cases people need decimal precision math in the bounds of what
the decimal128 standard provides. Most of us just do not want the float
drift and while a signed 64-bit integer is big, it has it's limitations and
a need for edge layer transformations be it presentation, API endpoints or
storing it in the database or other storage mediums.
4. Is it a lot of engine work? Yes, yes it is. Is it worth it? I think yes,
especially if we get buying from most of the active maintainers and get a
project going for it. This is not going to be the first or last big engine
project. But this might warrant a PHP 9 release in the end :)
5. But BCMath/GMP/etc!!! Well, extensions are optional. They are also not
as fast and they deal with strings. They are not as fast and you will have
to rely on that extension's methods that most math functions are
implemented and all that stuff. Frankly, I never had a use case where
BCMath was not an overkill. And doing number crunching with BCMath is just
slow due to them being strings internally. The use cases are just
different. They solve a different problem than a decimal128 does for the
language.

I think all the discussions on the subject have shown that BCMath RFC is
it's own thing and adding a decimal type to the PHP language/engine is it's
own thing. They are not mutually exclusive and solve different problems.

--=20

Arv=C4=ABds Godjuks
+371 26 851 664
arvids.godjuks@gmail.com
Telegram: @psihius https://t.me/psihius

--0000000000001b9af106175460af
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, 30 Apr 2024 at 09:19, Rowan T=
ommins [IMSoP] &lt;<a href=3D"mailto:imsop.php@rwec.co.uk">imsop.php@rwec.c=
o.uk</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex"><br>
<br>
On 28 April 2024 07:47:40 GMT-07:00, Robert Landers &lt;<a href=3D"mailto:l=
anders.robert@gmail.com" target=3D"_blank">landers.robert@gmail.com</a>&gt;=
 wrote:<br>
<br>
&gt;I&#39;m not so sure this could be implemented as an extension, there ju=
st<br>
&gt;isn&#39;t the right hooks for it.<br>
<br>
The whole point of my email was that &quot;this&quot; is not one single fea=
ture, but a whole series of them. Some of them can be implemented as an ext=
ension right now; some could be implemented as an extension by adding more =
hooks which would also be useful for other extensions; some would need chan=
ges to the core of the language.<br>
<br>
If the aim is &quot;everything you could possibly want in a decimal type&qu=
ot;, it certainly can&#39;t be an extension; if the aim is &quot;better sup=
port for decimals&quot;, then it possibly can.<br>
<br>
Regards,<br>
Rowan Tommins<br>
[IMSoP]<br>
</blockquote></div><div><br></div>I think setting some expectations in the =
proper context is warranted here.<div><br></div><div>1. Would a native deci=
mal type be good for the language? I would say we probably are not going to=
 find many if any people who would be against it.</div><div>2. Is there a n=
eed for it? Well, the whole world of e-commerce, accounting and all kinds o=
f business systems that deal with money in PHP world do not leave any room =
for doubt -=C2=A0<a href=3D"https://packagist.org/?query=3Dmoney">https://p=
ackagist.org/?query=3Dmoney</a> . The use case is right there :)</div><div>=
3. In most cases people need decimal precision math in the bounds of what t=
he decimal128 standard provides. Most of us just do not want the float drif=
t and while a signed 64-bit integer is big, it has it&#39;s limitations and=
 a need for edge layer transformations be it presentation, API endpoints or=
 storing it in the database or other storage mediums.</div><div>4. Is it a =
lot of engine work? Yes, yes it is. Is it worth it? I think yes, especially=
 if we get buying from most of the active maintainers and get a project goi=
ng for it. This is not going to be the first or last big engine project. Bu=
t this might warrant a PHP 9 release in the end :)</div><div>5. But BCMath/=
GMP/etc!!! Well, extensions are optional. They are also not as fast and the=
y deal with strings. They are not as fast and you will have to rely on that=
 extension&#39;s methods that most math functions are implemented and all t=
hat stuff. Frankly, I never had a use case where BCMath was not an overkill=
. And doing number crunching with BCMath is just slow due to them being str=
ings internally. The use cases are just different. They solve a different p=
roblem than a decimal128 does for the language.</div><div><br></div><div>I =
think all the discussions on the subject have shown that BCMath RFC is it&#=
39;s own thing and adding a decimal type to the PHP language/engine is it&#=
39;s own thing. They are not mutually exclusive and solve different problem=
s.<br><div><div><br></div><span class=3D"gmail_signature_prefix">-- </span>=
<br><div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"ltr"><div><br></=
div>Arv=C4=ABds Godjuks<div>+371 26 851 664</div><div><a href=3D"mailto:arv=
ids.godjuks@gmail.com" target=3D"_blank">arvids.godjuks@gmail.com</a></div>=
<div>Telegram: @psihius=C2=A0<a href=3D"https://t.me/psihius" target=3D"_bl=
ank">https://t.me/psihius</a></div></div></div></div></div></div>

--0000000000001b9af106175460af--