Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123007
Precedence: bulk
MIME-Version: 1.0
References: <37e79b28-ac4d-4413-9df8-54a123dfd1e3@redmagic.org.uk>
In-Reply-To: <37e79b28-ac4d-4413-9df8-54a123dfd1e3@redmagic.org.uk>
Date: Sat, 6 Apr 2024 17:32:29 -0700
Message-ID: <CAMrTa2HX2dCEr4uA5OumqwVbwd8E=upqiipFT_84b1J1HWOSVw@mail.gmail.com>
Subject: Re: [PHP-DEV] Native decimal scalar support and object types in
 BcMath - do we want both?
To: Barney Laurance <barney@redmagic.org.uk>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000a55add061576d398"
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--000000000000a55add061576d398
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Apr 6, 2024 at 4:07=E2=80=AFAM Barney Laurance <barney@redmagic.org=
.uk>
wrote:

> Hello,
>
> There are currently two proposals being discussed - *native decimal
> scalar type support* and *Support object type in BCMath*
>
> I've been getting involved in the discussion for the BCMath proposal, but
> not paying as much attention to the native decimal thread.
>
> But these seem like very similar things, so I'm wondering whether or not
> it makes sense to do both at once. They both seem like ways to represent
> and calculate with arbitrary precision decimal numbers.
>
> I'm not sure if they have distinct use cases. Are there some tasks where
> people would likely prefer one, and different tasks where they would pref=
er
> the other? Or should PHP internals choose just one of these options inste=
ad
> of potentially releasing both? It doesn't seem like a good idea to have t=
wo
> directly competing features for the same use case in one PHP release,
> unless there's a reason to favor each one in a different situation.
>
> Best wishes,
>
> Barney
>

The scalar arbitrary precision discussion is for an implementation that
would be in the range of 100x to 1000x faster than BCMath. No matter what
improvements are made to BCMath, there will still be strong arguments for
it, and until someone actually puts together an RFC, the BCMath library is
the only thing around.

Internals is just volunteers. The people working on BCMath are doing that
because they want to, the people working on scalar decimal stuff are doing
that because they want to, and there's no project planning to tell one
group to stop. That's not how internals works (to the extent it works).

Jordan

--000000000000a55add061576d398
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 Sat, Apr 6, 2024 at 4:07=E2=80=AFA=
M Barney Laurance &lt;<a href=3D"mailto:barney@redmagic.org.uk">barney@redm=
agic.org.uk</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"><u></u>

 =20

   =20
 =20
  <div>
    <p>Hello,<br>
      <br>
      There are currently two proposals being discussed - <i>native
        decimal scalar type support</i> and <i>Support object type in
        BCMath</i><br>
      <br>
      I&#39;ve been getting involved in the discussion for the BCMath
      proposal, but not paying as much attention to the native decimal
      thread.<br>
      <br>
      But these seem like very similar things, so I&#39;m wondering whether
      or not it makes sense to do both at once. They both seem like ways
      to represent and calculate with arbitrary precision decimal
      numbers.<br>
      <br>
      I&#39;m not sure if they have distinct use cases. Are there some task=
s
      where people would likely prefer one, and different tasks where
      they would prefer the other? Or should PHP internals choose just
      one of these options instead of potentially releasing both? It
      doesn&#39;t seem like a good idea to have two directly competing
      features for the same use case in one PHP release, unless there&#39;s
      a reason to favor each one in a different situation.<br>
      <br>
      Best wishes,<br>
      <br>
      Barney<br></p></div></blockquote><div><br></div><div>The scalar arbit=
rary precision discussion is for an implementation that would be in the ran=
ge of 100x to 1000x faster than BCMath. No matter what improvements are mad=
e to BCMath, there will still be strong arguments for it, and until someone=
 actually puts together an RFC, the BCMath library is the only thing around=
.</div><div><br></div><div>Internals is just volunteers. The people working=
 on BCMath are doing that because they want to, the people working on scala=
r decimal stuff are doing that because they want to, and there&#39;s no pro=
ject planning to tell one group to stop. That&#39;s not how internals works=
 (to the extent it works).<br></div><div><br></div><div>Jordan<br></div></d=
iv></div>

--000000000000a55add061576d398--