Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122996
Content-Type: multipart/alternative; boundary=Apple-Mail-FE257731-975F-44A8-9D32-0CEECD55A654
Content-Transfer-Encoding: 7bit
Precedence: bulk
Mime-Version: 1.0 (1.0)
Subject: Re: [PHP-DEV] Native decimal scalar support and object types in BcMath - do we want both?
Date: Sat, 6 Apr 2024 21:58:36 +0900
Message-ID: <F3DCB510-D149-43A3-B820-E605C9D87E1D@sakiot.com>
References: <37e79b28-ac4d-4413-9df8-54a123dfd1e3@redmagic.org.uk>
Cc: internals@lists.php.net
In-Reply-To: <37e79b28-ac4d-4413-9df8-54a123dfd1e3@redmagic.org.uk>
To: Barney Laurance <barney@redmagic.org.uk>
From: saki@sakiot.com (Saki Takamachi)


--Apple-Mail-FE257731-975F-44A8-9D32-0CEECD55A654
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Hi Barney,
> There are currently two proposals being discussed - native decimal scalar t=
ype support and Support object type in BCMath
>=20
> I've been getting involved in the discussion for the BCMath proposal, but n=
ot paying as much attention to the native decimal thread.
>=20
> But these seem like very similar things, so I'm wondering whether or not i=
t makes sense to do both at once. They both seem like ways to represent and c=
alculate with arbitrary precision decimal numbers.
>=20
> I'm not sure if they have distinct use cases. Are there some tasks where p=
eople would likely prefer one, and different tasks where they would prefer t=
he other? Or should PHP internals choose just one of these options instead o=
f potentially releasing both? It doesn't seem like a good idea to have two d=
irectly competing features for the same use case in one PHP release, unless t=
here's a reason to favor each one in a different situation.
>=20

(I'm the proposer on the BCMath thread, so my opinion may be a bit biased.)

The "areas" being discussed are certainly close.  However, I believe that th=
e goals of the proposals and the time and effort required to realize them wi=
ll vary greatly.

Regards.

Saki=

--Apple-Mail-FE257731-975F-44A8-9D32-0CEECD55A654
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div>Hi Barney,</div><div><blockquote type=3D=
"cite"><div dir=3D"ltr"><p>There are currently two proposals being discussed=
 -&nbsp;<i>native decimal scalar type support</i>&nbsp;and&nbsp;<i>Support o=
bject type in BCMath</i><br><br>I've been getting involved in the discussion=
 for the BCMath proposal, but not paying as much attention to the native dec=
imal thread.<br><br>But these seem like very similar things, so I'm wonderin=
g 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'm not sure if they have distinct use cases. Are there some tasks where pe=
ople would likely prefer one, and different tasks where they would prefer th=
e other? Or should PHP internals choose just one of these options instead of=
 potentially releasing both? It doesn't seem like a good idea to have two di=
rectly competing features for the same use case in one PHP release, unless t=
here's a reason to favor each one in a different situation.</p></div></block=
quote><br></div><div>(I'm the proposer on the BCMath thread, so my opinion m=
ay be a bit biased.)</div><div><br></div><div>The "areas" being discussed ar=
e certainly close. &nbsp;However, I believe that the goals of the proposals a=
nd the time and effort required to realize them will vary greatly.</div><div=
><br></div><div>Regards.</div><div><br></div><div>Saki</div></body></html>=

--Apple-Mail-FE257731-975F-44A8-9D32-0CEECD55A654--