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. 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
