Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123017
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
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?
In-Reply-To: <40553F28-2EC2-475A-BD8E-1D6517AA2A51@rwec.co.uk>
Cc: internals@lists.php.net
Date: Sun, 7 Apr 2024 23:38:04 +0900
Message-ID: <2B518F62-B774-45C9-82A2-EF6653AAE34E@sakiot.com>
References: <40553F28-2EC2-475A-BD8E-1D6517AA2A51@rwec.co.uk>
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
From: saki@sakiot.com (Saki Takamachi)

Hi Rowan,

> 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 f=
ixed-precision number type. For instance, how to specify precision and round=
ing for operations like division. I haven't seen anywhere in the discussion w=
here the answer was "that's how it already works, and we're not adding new f=
eatures".

> Is there anything in the proposal which would actually be different if it w=
as based on a different library, and if not, should we be designing a Number=
Interface which multiple extensions could implement? Then Jordan's search fo=
r a library with better performance could lead to new extensions implementin=
g that interface, even if they have portability or licensing problems that m=
ake them awkward to bundle in core.
>=20
> Finally, there's the separate discussion about making a new "scalar type".=
 As I said in a previous email, I'm not really sure what "scalar" means in t=
his context, so maybe "integrating the type more directly into the language"=
 is a better description? That includes memory/copying optimisation (potenti=
ally linked to Ilija's work on data classes), initialisation syntax (which c=
ould be a general feature), and accepting the type in existing functions (so=
mething frequently requested for custom array-like types).
>=20
> 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.

I agree that the essence of the debate is as you say.
However, an argument must always reach a conclusion based on its purpose, an=
d combining two arguments with different purposes can make it unclear how to=
 reach a conclusion.

If we were to merge these two debates, what should be on our agenda? It woul=
d probably be reasonable to have a limited joint discussion on the common po=
int between the two arguments, namely, "how to express numbers," and then re=
turn to each of their own arguments.

However, it is not desirable for the venue for discussion to change dependin=
g on the content of the discussion, so I think it will be difficult to integ=
rate them.

Your hope is probably that by combining the discussions, better ideas will e=
merge. IMHO, that should really be a "new discussion", perhaps in this threa=
d where we're talking now.

Regards.

Saki=