Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123011
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?
Date: Sun, 7 Apr 2024 19:44:22 +0900
Message-ID: <A33F4EE9-398E-471B-B6EF-1DCC019B0283@sakiot.com>
References: <240D79D1-708D-45A7-9989-D28893955D6E@rwec.co.uk>
Cc: internals@lists.php.net
In-Reply-To: <240D79D1-708D-45A7-9989-D28893955D6E@rwec.co.uk>
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
From: saki@sakiot.com (Saki Takamachi)

Hi Rowan,

>> On 7 April 2024 01:32:29 BST, Jordan LeDoux <jordan.ledoux@gmail.com> wro=
te:
>>=20
>> Internals is just volunteers. The people working on BCMath are doing that=

>> because they want to, the people working on scalar decimal stuff are doin=
g
>> 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).
>=20
> I kind of disagree. You're absolutely right the detailed effort is almost a=
lways put in by people working on things that interest them, and I want to m=
ake clear up front that I'm extremely grateful to the amount of effort peopl=
e do volunteer, given how few are paid to work on any of this.
>=20
> However, the goal of the Internals community as a whole is to choose what c=
hanges to make to a language which is used by millions of people. That absol=
utely involves project planning, because there isn't a marketplace of PHP fo=
rks with different competing features, and once a feature is added it's very=
 hard to remove it or change its design.
>=20
> If - and I stress I'm not saying this is true - IF these two features have=
 such an overlap that we would only want to release one, then we shouldn't j=
ust accept whichever is ready first, we should choose which is the better so=
lution overall. And if that was the case, why would we wait for a polished i=
mplementation of both, then tell one group of volunteers that all their hard=
 work had been a waste of time?
>=20
> So I think the question is very valid: do these two features have distinct=
 use cases, such that even if we had one, we would still want to spend time o=
n the other? Or, should we decide a strategy for both groups to work togethe=
r towards a single goal?
>=20
> That's not about "telling one group to stop", it's about working together f=
or the benefit of both users and the people volunteering their effort, to wh=
om I am extremely grateful.
>=20
> Regards,
> Rowan Tommins
> [IMSoP]

I don't think the two threads can be combined because they have different go=
als. If one side of the argument was, "How about to add BCMath?" then perhap=
s we should merge the discussion. But BCMath already exists and the agenda i=
s to add an OOP API.

In other words, one is about adding new features, and the other is about imp=
roving existing features.

I agree that it would be wise to merge issues that can be merged.

Regards.

Saki=