Re: Could we kill call_user_func?

Am 15.3.2013 um 18:57 schrieb Stas Malyshev <smalyshev@sugarcrm.com>: > Hi! > >> why not enable then this "getCallback()();"? > > There's an RFC for that: �e(Ld' > �K͇����https://wiki.php.net/rfc/fcallfcall > but it has some edge cases which I didn't have time to figure out yet. Is it possible to add this alternative rule for function_call in zend_language_parser.y: parenthesis_expr { zend_do_begin_dynamic_function_call(&$1, 0 TSRMLS_CC); } function_call_parameter_list { zend_do_end_function_call(&$1, &$$, &$3, 0, $2.u.op.opline_num TSRMLS_CC); zend_do_extended_fcall_end(TSRMLS_C); } So that you can write ($this->closure)(); (for invoking Closures instead of first assigning it, then calling the Closure or writing $this->closure->invoke()) Or write (getCallback())(). There should be then no edge cases as it is properly delimited by the parenthesis. I've shortly tested this with no new bugs. Short example: function a () { return "b"; } function b () { return "c"; } print (a())()."\n"; // prints c function a () { return function () { print "a\n"; }; } (a())(); // prints a I also think this with parenthesis around it it is clearer what's being done: the first part evaluated and then the second executed. (If I would have to choose I would prefer the parenthesis...) Bob Weinand p.s.: I'm wondering why, with this little patch, (function () { print "a"; })(); is throwing a fatal error telling me a function name must be a string while ($temp = function () { print "a"; })(); is working perfectly?! (I think this is the condition which fails: http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_vm_def.h#2676, but I'm not 100% sure and now I'm too tired to investigate further into it...)