Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116630
MIME-Version: 1.0
References: <CAMrTa2FB-EVGq29oLCU8fYkMYi+KsQiEAFv1xxMFO7vnm8e6=Q@mail.gmail.com>
 <CA+kxMuQqGpkuqwFLrW29G38aOUNbvXM6Dq=P8NXt=1zai_=zxA@mail.gmail.com> <CAMrTa2H3Su5GBsxqie3hs9ugDVzMgu0gPUxFFDbFhQcj0QCT7A@mail.gmail.com>
In-Reply-To: <CAMrTa2H3Su5GBsxqie3hs9ugDVzMgu0gPUxFFDbFhQcj0QCT7A@mail.gmail.com>
Date: Sun, 12 Dec 2021 19:10:25 +0000
Message-ID: <CA+kxMuTwY6Jjw8_YE8-Oahz_7wQAtbJ6XCL+VO=OvkVhNxAHpA@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)

On Sat, 11 Dec 2021 at 19:13, Jordan LeDoux <jordan.ledoux@gmail.com> wrote:
>
> I *think* that all of the things you mentioned will need similar
> updates to work correctly with this RFC even if it was done
> with plain old magic methods instead.

No, that's not true. Codesniffer and all the other tools parse magic
methods just fine. Stuff like the coverage notation for PHPUnit would
understand `@covers BigNumber::__plus` just fine.

The main piece of work each of them would need to do to support this
RFC, if it was based on magic methods, is being able to understand
that objects can work with operators:

```
$foo = new BigNumber(5);
$foo + 5; // Check that BigNumber implements the magic method __plus
```

That is far less work than having to add stuff to parse a new way to
declare functions.

Jordan LeDoux wrote:
>
> Danack wrote:
>> # "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.
>
> First, you can still get the closure for the operator implementation
> from Reflection if you really, really need it.

Sorry, but I just find that a bizarre thing to suggest. Introducing a
new type of function that can only be called in a particular way needs
to have really strong reasons for that, not "oh you can still call it
through reflection".

I think you've taken the position that using the symbols are cool, and
you're reasoning about how the RFC should operate from decision.

I'm not sure I can make a reasonable argument against it that you
would find persuasive, but to me it's adding a non-trivial amount of
complexity, which tips the RFC from being acceptable, to not.

cheers
Dan
Ack