Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123013
Feedback-ID: id5114917:Fastmail
Date: Sun, 07 Apr 2024 15:02:49 +0100
To: internals@lists.php.net
Subject: =?US-ASCII?Q?Re=3A_=5BPHP-DEV=5D_Native_decimal_scalar_support_?=
 =?US-ASCII?Q?and_object_types_in_BcMath_-_do_we_want_both=3F?=
User-Agent: K-9 Mail for Android
In-Reply-To: <A33F4EE9-398E-471B-B6EF-1DCC019B0283@sakiot.com>
References: <240D79D1-708D-45A7-9989-D28893955D6E@rwec.co.uk> <A33F4EE9-398E-471B-B6EF-1DCC019B0283@sakiot.com>
Message-ID: <40553F28-2EC2-475A-BD8E-1D6517AA2A51@rwec.co.uk>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")



On 7 April 2024 11:44:22 BST, Saki Takamachi <saki@sakiot=2Ecom> wrote:
>I don't think the two threads can be combined because they have different=
 goals=2E If one side of the argument was, "How about to add BCMath?" then =
perhaps we should merge the discussion=2E But BCMath already exists and the=
 agenda is to add an OOP API=2E
>
>In other words, one is about adding new features, and the other is about =
improving existing features=2E

While I appreciate that that was the original aim, a lot of the discussion=
 at the moment isn't really about BCMath at all, it's about how to define a=
 fixed-precision number type=2E For instance, how to specify precision and =
rounding for operations like division=2E I haven't seen anywhere in the dis=
cussion where the answer was "that's how it already works, and we're not ad=
ding new features"=2E

Is there anything in the proposal which would actually be different if it =
was based on a different library, and if not, should we be designing a Numb=
erInterface which multiple extensions could implement? Then Jordan's search=
 for a library with better performance could lead to new extensions impleme=
nting that interface, even if they have portability or licensing problems t=
hat make them awkward to bundle in core=2E

Finally, there's the separate discussion about making a new "scalar type"=
=2E As I said in a previous email, I'm not really sure what "scalar" means =
in this context, so maybe "integrating the type more directly into the lang=
uage" is a better description? That includes memory/copying optimisation (p=
otentially linked to Ilija's work on data classes), initialisation syntax (=
which could be a general feature), and accepting the type in existing funct=
ions (something frequently requested for custom array-like types)=2E

In other words, looking at how the efforts overlap doesn't have to mean ab=
andoning one of them, it can mean finding how one can benefit the other=2E

Regards,
Rowan Tommins
[IMSoP]