Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116811
MIME-Version: 1.0
References: <CAMrTa2Emxro81j7UMA5QZ+wCOY7g46LSotLRD4oUG7HEfqSD0A@mail.gmail.com>
 <81fe282c-45d6-f54a-16b9-9dfffedaaa33@alec.pl>
In-Reply-To: <81fe282c-45d6-f54a-16b9-9dfffedaaa33@alec.pl>
Date: Wed, 5 Jan 2022 01:36:23 -0800
Message-ID: <CAMrTa2Gx5YOaNYD0Pr=RrR=w1BCzS_=KXecpV78FjJua78_9Nw@mail.gmail.com>
To: Aleksander Machniak <alec@alec.pl>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000074d92105d4d27df3"
Subject: Re: [PHP-DEV] [VOTE] User Defined Operator Overloads
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--00000000000074d92105d4d27df3
Content-Type: text/plain; charset="UTF-8"

On Wed, Jan 5, 2022 at 12:26 AM Aleksander Machniak <alec@alec.pl> wrote:

>
> - what is the performance impact?
>

Each operator evaluation is very slightly better than the equivalent
function call, since the VM call chain is very slightly simpler, but for
most purposes you can think of the performance as being the same as a
method call. This is quite a bit slower than most operator evaluations
(which are lightning fast compared to function calls), however this *only*
affects *objects* used with operators, which currently always result in a
fatal error. So in that sense, there is no performance impact.


> - why "[public] operator" and not "operator function"?
>

As many people in this thread have pointed out, it's possible for less
experienced developers to do something truly devious with this (the same
way that they can with __get, __set, or __toString). I wanted to avoid
using the function keyword at all, because I wanted the code itself to
mentally prepare the programmer to treat these differently than arbitrary
functions. As I mentioned in a previous email, some will view this as
wishy-washy, but that decision was done after consulting a specialist that
I know in the field of Human Centered Design (the field of designing
technology so that it is used correctly by design alone). That is, in
truth, my largest reason for wanting the operator keyword, but it's also
something that I invested nearly two months of study and consultation into.
That makes it difficult for me to correctly convey that understanding to
other people here via email, so I have mostly restricted my arguments to
other things. I find myself in the odd position of not really being able to
dump all of the research I did here for everyone else, because frankly, no
one on this list *should* need to invest a week of studying to understand
an RFC.

So unfortunately, my best argument in favor of this is one I can't really
make, but that *is* the reason that I went this route.


> - what about precedence, i.e. what happens with $a + $b * $c? there's no
> clear answer
>

Precedence is handled by the compiler and how it handles the opcodes.
That's independent of any of the changes in this RFC, since the opcodes for
all the operators are the same with or without operator overloads. So the
precedence will be the same if $a, $b, and $c are ints or objects, even if
we later (for some reason) changed the precedence of the operators.


> - why not allow the tilde operator to be used in a different context?,
> e.g. in PostgreSQL it is used as a regular expression match, e.g.
>    $a ~ '^[a-z]+$'
>

This would involve changing the opcode evaluation itself, instead of just
implementing a do_operation handler in zend_class_entry. It would introduce
much more surface for buggy behavior and be a great deal of additional
effort for that single operator.


> - the Implied Operators table does not mention ~= operation.
>

The ~= operator does not exist in PHP because the ~ operator is a unary
operator in PHP (bitwise not).

See:

- https://www.php.net/manual/en/language.operators.assignment.php
- https://3v4l.org/N9OYF


> - I don't like the Reflection API changes
>

Please suggest changes then. It seems probable this will not pass in this
incarnation, so knowing what things to improve before bringing it back
would be helpful.

Jordan

--00000000000074d92105d4d27df3--