On Wed, Jan 5, 2022 at 12:26 AM Aleksander Machniak <a...@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
