Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116620
MIME-Version: 1.0
References: <CAMrTa2FB-EVGq29oLCU8fYkMYi+KsQiEAFv1xxMFO7vnm8e6=Q@mail.gmail.com>
In-Reply-To: <CAMrTa2FB-EVGq29oLCU8fYkMYi+KsQiEAFv1xxMFO7vnm8e6=Q@mail.gmail.com>
Date: Sat, 11 Dec 2021 15:15:34 +0000
Message-ID: <CA+kxMuQqGpkuqwFLrW29G38aOUNbvXM6Dq=P8NXt=1zai_=zxA@mail.gmail.com>
To: Jordan LeDoux <jordan.ledoux@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [RFC] User Defined Operator Overloads (v0.6)
From: Danack@basereality.com (Dan Ackroyd)

Hi Jordan,

On Thu, 9 Dec 2021 at 20:12, Jordan LeDoux <jordan.ledoux@gmail.com> wrote:
>
> Hello internals,
>
> I last brought this RFC up for discussion in August, and there was
> certainly interesting discussion. Since then there have been many
> improvements, and I'd like to re-open discussion on this RFC.

In general I'm in favour of this RFC; a few months ago I was
programming something and operator overloads would have been a good
solution, but then I remembered I was using PHP, and they haven't been
made possible yet.

However.....I think the new 'operator' keyword is probably not the way
to go. Although it's cute, it has some significant downsides.

There are quite a few downstream costs for making a new type of
methods in classes. All projects that analyze code (rector,
codesniffer, PHPStorm, PhpStan/Psalm, PHPUnit's code coverage
annotations etc) would have to add a non-trivial amount of code to not
bork when reading the new syntax. Requiring more code to be added and
maintained in PHP's builtin Reflection extension is also a cost.
That's quite a bit of work for a feature that has relatively rare
use-cases.

I just don't agree/understand with some of the reasoning in the RFC of
why using symbols is preferable.

"In such a situation, using magic methods would not be desired, as any
combination of symbols may be used for the new infix. The restrictions
on function names, such as needing to reserve the & to mark a function
as being by-reference, would place limitations on such future scope."

I don't get this. The magic methods in previous drafts of the RFC
don't have a problem with & as the methods are named with 'two
underscores' + name e.g. __bitwiseAnd. That does't appear to cause a
problem with an ampersand?

"By representing the implementations by the symbols themselves, this
RFC avoids forcing implementations to be mislabeled with words or
names which do not match the semantic meaning of that symbol in the
program context.

The name of the function (e.g. __add) always refers to the symbol used
where it is used, not what it is doing.

If the code is `$a + $b` then that is an addition operator, when the
code is read. If I was reading the code, and I saw that either  $a or
$b were objects, I would know to go looking for an __add magic method.

" '// This function unions, it does not add'"

Then that is probably an example of an inappropriate use of operator
overloads, and so shouldn't be used as a justification for a syntax
choice.

# "Non-Callable - Operand implementations cannot be called on an
instance of an object the way normal methods can."

I think this is just wrong, and makes the RFC unacceptable to me.

Although most of the code I write is code that just performs
operations as I see fit, some of the time the operations need to be
driven by user data. Even something simple like a
calculator-as-a-service would need to call the operations dynamically
from user provided data.

I also have an aesthetic preference when writing tests to be explicit
as possible, rather than concise as possible e.g.

$foo->__add(5, OperandPosition::LeftSide);
$foo->__add(5, OperandPosition::RightSide);

instead of:

$foo + 5;
5 + $foo

As I find that easier to reason about.

cheers
Dan
Ack

/congratulations on stunning the audience into silence otherwise though.