Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122008
MIME-Version: 1.0
References: <18c42fdbb30.2831.17a3710df6d58f02ca570cc47e197a63@interi.co>
 <CAFPFaMLZ3MeGXt5OPmAkwM-n-eZcp1gT7RQCnpXSyHxZThOn2g@mail.gmail.com>
 <CAOyH9yReYorVd1jDPyk_O73JUn1VvqEAz0Fb7mvQ6ke9k9FcZA@mail.gmail.com>
 <CAFPFaMKoH1PD_qaBPLw9pwid0NB5zyZYM7AgogYOWFhPVysEwQ@mail.gmail.com>
 <CAPzBOBMw-mjjuKEX1udq2XaKGcRneT_DWinqP9aAtU0oGfLhzw@mail.gmail.com>
 <CAFPFaMJY=Q+vaFbhA1Xe-9xun_LPkdhL-oX2opGyV7uA_8v4Pg@mail.gmail.com> <CAPzBOBMVViMjZk2d0J77Ck7qktCbMnN1BpDogx=u40=gbYR7ZA@mail.gmail.com>
In-Reply-To: <CAPzBOBMVViMjZk2d0J77Ck7qktCbMnN1BpDogx=u40=gbYR7ZA@mail.gmail.com>
Date: Fri, 15 Dec 2023 12:31:56 -0800
Message-ID: <CAMrTa2FzhFKYM+ZOkbNXTN2_uhEvmOdvCepF8_nG0_cLAHscOQ@mail.gmail.com>
To: Robert Landers <landers.robert@gmail.com>
Cc: "G. P. B." <george.banyard@gmail.com>, Alexander Pravdin <alex.pravdin@interi.co>, 
	internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000006ca05f060c924bf3"
Subject: Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--0000000000006ca05f060c924bf3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Dec 15, 2023 at 12:14=E2=80=AFAM Robert Landers <landers.robert@gma=
il.com>
wrote:

>
> nobody will likely ever try this again, at least in the foreseeable
> future. With comments like that, there is simply no way forward.
> There's no convincing (at least via email) and by that point, it's too
> late anyway, they already voted but didn't even show up for the
> discussion that happened for weeks. Literally wasting everyone's time.
> The only way we'd ever get something like this passed is if someone
> proposes an RFC that prevents people from voting based on
> political/personal reasons and restricts voting "no" to technical
> reasons only; or some voters reopen one of the original RFC's for a
> revote and leave it in the "Pending Implementation" section as needing
> an implementation.
>
> The fact that people can and do vote "no" for no other reason than
> they "don't like it" or they "don't want to use it" leaves a bad taste
> in my mouth.
>

Okay, so I'm probably the most affected by this, considering we're
discussing my proposal which was declined and I spent over 400 hours of
work on it prior to the vote. So please understand where I'm coming from
when I say this: I firmly believe that people should be allowed to vote no
on an RFC simply because they feel that it "doesn't belong in PHP". That is
a voter taking a position on what the language is for, how it should be
designed from a more broad perspective, and I think it's important to have
that in order to maintain a productive language that does its job well.

The main issue I have discovered through this experience is that some
people have difficulty or lack the experience necessary to separate an
opinion about the language design philosophy from what would be personally
useful to *them*. That is a problem, but it's a problem that is just part
of working collaboratively with humans. It's not unique to this group, to
PHP, or to this situation.

The reason, for everyone else reading, that this is relevant to the current
discussion about a scalar decimal type is that this is likely to face some
similar pushback. This email will go out to hundreds of people, but only a
few are going to reply, and most of the people currently participating in
this discussion do not have voting rights, so this RFC if it's worked on
will have to be developed without the feedback of the people who actually
decide whether it goes into the language.

A scalar decimal type will be extremely useful for certain types of
applications, foundationally critical to other types of applications, and
completely unused for others. A big part of writing this RFC would be
explaining to the people who do not work on any applications that benefit
why it would be good to include it in the language anyway.

A scalar decimal type would create a hard dependency on libmpdec, which I
also expect to be something that needs to be addressed. MPDec is licensed
under the Simplified BSD License. I *think* it could be bundled if needed,
but it couldn't be relicensed with the PHP License itself.

Jordan

--0000000000006ca05f060c924bf3--