Req #66368 [Opn]: Operators should also be functions

Edit report at https://bugs.php.net/bug.php?id=66368&edit=1 ID: 66368 Updated by: cmb@php.net Reported by: chriswarbo at gmail dot com Summary: Operators should also be functions Status: Open Type: Feature/Change Request Package: *General Issues Operating System: Irrelevant PHP Version: Irrelevant Block user comment: N Private report: N New Comment: FTR: a respective "Operator functions" RFC is currently under discussion: <https://wiki.php.net/rfc/operator_functions>. Previous Comments: ------------------------------------------------------------------------ [2014-01-02 12:23:24] chriswarbo at gmail dot com It is sufficient to do: $o = function($l, $r) { return $l + $r; }; But after defining such a function for the umpteenth time, I decided to raise this issue. I don't think I'm alone in using such definitions, since it's a common-enough pattern that we had array_sum built in to the language even before we had lambdas and array_reduce (array_sum is just array_reduce curried with $o and 0). One solution would be to build in functions like $o to prevent the need to define them over and over in-line or in libraries, but I'd rather not be 'that guy' who wants his own helper-functions built-in, since adding new functions bloats the language and, more importantly, burdens developers with extra complexity ("Should I use + or $o?"). Instead, I think it's an opportunity to fix the treatment of operators, especially since functions like $o are just eta-expansions of operators, and eta-expansion is always a useless transformation: function eta($f) { return function ($x) { return $f($x); }; } call_user_func(eta($x), $y) === call_user_func($x, $y) ------------------------------------------------------------------------ [2014-01-01 14:43:23] krakjoe@php.net Ok, I understand a bit clearer what you're asking for ... but don't really see why; I cannot imagine a time where: $o = '+'; $o(10, 20); Is required such that: $o = function($l, $r) { return $l + $r; }; Does not suffice. Maybe someone else will get it, I don't ... ------------------------------------------------------------------------ [2014-01-01 13:04:19] chriswarbo at gmail dot com As for "[]" and "->" being functions (or function-like), consider the following: function subscript($array, $index) { return $array[$index]; } array_map('subscript', $my_arrays, range(0, 9)); function prop($object, $property) { return $object->$property; } array_map('prop', $my_objects, $props); Personally I don't use the above functions, but I make heavy use of a function "lookup" which does both (based on the argument's type) plus a few bells and whistles (recursively looking up an array of identifiers, exception and error handling for magic methods, etc.). ------------------------------------------------------------------------ [2014-01-01 12:38:09] chriswarbo at gmail dot com I don't think it's necessary to replace operators with functions; it's more about allowing operators to be used in the same way as functions, regardless of how they're implemented. The crucial difference at the moment can be seen by PHP's distinction between calling named functions directly and indirectly (via a string identifier): // Direct my_function(10, 20); // Indirect $f = 'my_function'; $f(10, 20); This is a bit clunky (compared to "$f = my_function;" in most other languages), but it gets the job done. Let's compare it to operators: // Direct 10 + 20; // Indirect $o = '+'; $o(10, 20); // Fatal error: Call to undefined function +() This is the essence of all the above examples: we can't pass around identifiers for operators like we can for named functions. I have no objections to the distinction between operators and functions, except for this advantage that functions currently have over operators. Solving this from inside PHP requires wrapping every operator with a function, but solving it at the implementation level gives us more options to play with. In particular, we can use PHP's 'clunky' method of indirect calls to our advantage. Since functions are identified by strings, and those strings can contain arbitrary runtime data, the PHP interpreter is forced to use a lookup procedure to find the right function. This gives us an opportunity to inject some extra logic, for example replacing the current fatal error trigger with a switch statement for each operator, defaulting to the fatal error. ------------------------------------------------------------------------ [2014-01-01 09:10:06] krakjoe@php.net I've read this, several times, last night and this morning. I cannot make good sense out of your request, I don't know what you're asking for. Some of this just doesn't make sense (why on earth should [] or -> be a function). I'm sure it all makes sense to you in your head, but I'm having a hard time understanding what it is you want to be implemented. By title alone; you do not want all operators and some language constructs to be functions, that would destroy performance, obviously. You don't appear to want operator overloading because this appears focused on primitive types. What is it exactly that you want ? Sorry if the explanation is there, I just don't see it ... ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=66368 -- Edit this bug report at https://bugs.php.net/bug.php?id=66368&edit=1