Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116806
MIME-Version: 1.0
References: <CAMrTa2Emxro81j7UMA5QZ+wCOY7g46LSotLRD4oUG7HEfqSD0A@mail.gmail.com>
 <CADyq6sKP6fztfF54e_VTHJRMcB8b0_TahMTTY0hw8LAgciY61w@mail.gmail.com>
 <CAB-BujZB31Ccw6nhN9PG1-VDqt8YkijsYUBYPxJ-Ss1Ng4KJ+w@mail.gmail.com>
 <CADyq6sLh+e74qeMrOuX1_PdN40Jw7m=3wMGMmdF-rwXkJLS1mg@mail.gmail.com>
 <3225c921-9b26-d2e0-f76f-45fff6f5a12a@processus.org> <e0358c86-622e-4347-a36c-2e8e16759004@www.fastmail.com>
 <40a1e5fa-396d-d9ef-93ab-6fcfb5054092@processus.org> <CAMrTa2FCGwkJ+kOHbyh4e=jWOBaDtb8iJiUDjqSEpA-Yts7Cpg@mail.gmail.com>
 <CAB-BujZtUnesM_cWBS1T0R4=WA5MBjq6aUsXaEB5n99Pwq2wVQ@mail.gmail.com>
 <CAMrTa2GKG_c_dCt6urpAY4S=pSWKaMBCAZCC6CCu8A2b+FdXwA@mail.gmail.com> <CADyq6sKydDgrq+hJwrsUOsO+=Zk0sK5xnyhqz1FG3keaWy5tGg@mail.gmail.com>
In-Reply-To: <CADyq6sKydDgrq+hJwrsUOsO+=Zk0sK5xnyhqz1FG3keaWy5tGg@mail.gmail.com>
Date: Tue, 4 Jan 2022 18:19:03 -0800
Message-ID: <CAMrTa2GAqwFLzZUBeoT=63=xWUoHBJj8uwmi8DxhZkbHwONFFA@mail.gmail.com>
To: Marco Pivetta <ocramius@gmail.com>
Cc: Andreas Hennings <andreas@dqxtech.net>, Pierre <pierre-php@processus.org>, 
	Larry Garfield <larry@garfieldtech.com>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000006f844805d4cc61cc"
Subject: Re: [PHP-DEV] [VOTE] User Defined Operator Overloads
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--0000000000006f844805d4cc61cc
Content-Type: text/plain; charset="UTF-8"

On Tue, Jan 4, 2022 at 1:27 AM Marco Pivetta <ocramius@gmail.com> wrote:

>
> I know you're picking on details here, but believe me, I'm serious when
> I'm saying "use matlab".
>
> In fact, I did work on financial products where (from Java PHP and Python)
> we used the MATLAB Compiler to create binaries and dynamic libraries, which
> would then do the heavy lifting around the financial models that were in
> use.
>
>
 "Use an external tool that already exists to accomplish this task" is not,
in my view, a legitimate reason to reject a feature from the language on
its own. I see it as a relevant additional detail justifying a rejection,
given that the rejection is for other reasons. That is, it's more of a
justification for "this is why the rejection isn't that bad" than it is
"this is *why* it should be rejected". You can literally use this argument
to reject *any* feature, which means that it's application is entirely
arbitrary.

Let me phrase this another way: if I came later with a different RFC that
has a main use case of mathematics, would you reject that as well on the
basis that mathematics *should not* be well done in PHP? I'm not asking
rhetorically, I'm legitimately wanting an answer to this question. Do I
need to find and demonstrate non-mathematics use cases on future RFCs in
order to have them seriously considered?

Mathematics is not niche. I simply disagree on that. And it sort of seems
that you do as well, since *immediately* before saying mathematics was
niche you also said that spreadsheets run the world.

If this RFC is rejected, as seems likely at this point barring some changed
minds, I can certainly accept that. Several of the yes votes so far on this
RFC also told me they would likely vote no out-of-hand when I first
discussed this RFC back in August, but I was able to listen to their
concerns, continue improving the RFC, and also present my arguments for why
it is an important and impactful feature to them. They provided me with
concrete objections that I could consider and see if there was a way for me
to address and incorporate into the feature design, and it made the RFC
better. But virtually all of the no votes so far declined to participate in
any of the three threads that I had soliciting feedback, in the chat
discussions over the last 5 months, or even in this thread.

I have one actionable bit of feedback so far from Nikita, suggesting that
the RFC would be improved with different syntax.

I am at a total loss at this point as to how to proceed with other
contributions I would like to make to PHP in the future, as the only
conclusion I can draw right now is that math improvements simply aren't
important or even wanted.

Can I expect this for other math related RFCs, or is this dogmatic about
operator overload specifically? I have no clue, and at the very least, I
would like to learn that.

Jordan

--0000000000006f844805d4cc61cc--