Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116768
MIME-Version: 1.0
References: <CAMrTa2Emxro81j7UMA5QZ+wCOY7g46LSotLRD4oUG7HEfqSD0A@mail.gmail.com>
In-Reply-To: <CAMrTa2Emxro81j7UMA5QZ+wCOY7g46LSotLRD4oUG7HEfqSD0A@mail.gmail.com>
Date: Mon, 3 Jan 2022 02:06:51 +0100
Message-ID: <CADyq6sKP6fztfF54e_VTHJRMcB8b0_TahMTTY0hw8LAgciY61w@mail.gmail.com>
To: Jordan LeDoux <jordan.ledoux@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000007268f505d4a32380"
Subject: Re: [PHP-DEV] [VOTE] User Defined Operator Overloads
From: ocramius@gmail.com (Marco Pivetta)

--0000000000007268f505d4a32380
Content-Type: text/plain; charset="UTF-8"

Hey Jordan,

I've voted "no" on this one: infix functions may have been interesting, but
adding a whole new type system around operators is really not worth it,
given:

 * Added AST nodes
 * Added method definitions for niche use-cases
 * Complexity in support for static analysis tools

I personally don't see a reason to introduce all this for examples like the
one with GMP, which was more readable before adopting userland custom
operators.

In addition to all that, we didn't even achieve custom operators anyway:
it's just the built-in ones (this is why I mentioned infix functions), and
the precedence, number and type of operands are fixed too (yes, it is a
sensible starting choice, but very little "custom" about it).

Overall, your RFC is exactly what I would expect a custom operator RFC for
PHP to look like: I just don't think the feature is needed at all, as it
only makes the language much more complex, for rare cases that I hope I
will never ever have to debug in future.

Greets,

Marco

--0000000000007268f505d4a32380--