On Sat, Dec 11, 2021, at 9:15 AM, Dan Ackroyd wrote:
> Hi Jordan,
>
> On Thu, 9 Dec 2021 at 20:12, Jordan LeDoux <jordan.led...@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.
I too far prefer this RFC to its predecessors, and hope it passes in some form.
> 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.
I believe the intent is for things like dot product.
int * int
This is known as "multiplication", or we could abbreviate it __mul if we felt
like it.
vector * vector
This is known as a "Dot product", or "scalar product", and is not really the
same as multiplication. It uses effectively the same operator sigil, though.
There's also cross-product, which nominally uses `x` as a symbol in
mathematics. Which is... often also translated to * in code, but is a very
different operation and is not multiplication as we know it, nor is it the same
as dot product.
So __mul() would be an incorrect name for either one. Using symbols, however,
would (with some future extension to make it extensible) allow for:
operator *(Vector $v, $left) { ... }
operator x(Vector $v, $left) { ... }
which (for someone who knows vector math) is a lot more self-explanatory than
"which one is being mistranslated as multiply?"
At least, that's my understanding of the argument for it. The point about
making meta programming more difficult is certainly valid, though. Personally
I think I could go either way on this one, as I see valid arguments either
direction.
> # "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 largely agree here. I don't know if it's because of the `operator` choice or
not, but being able to call an operator dynamically is important in many use
cases. It doesn't have to be a pristine syntax, but some way to do that
dynamically (without having a big match statement everywhere you need to) would
be very welcome.
Another question: Can an interface or abstract class require an operator to be
implemented? That's not currently discussed at all. (I would expect the
answer to be Yes.)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
