Hi,
On Fri, 2013-07-19 at 12:36 -0400, Daniel Lowrey wrote: > I have a simple question about the callability of language constructs and > whether or not that's something that might change in the future. Consider: > > var_dump(is_callable('echo')); // bool(false) > var_dump(call_user_func('echo', 'foo')); // E_WARNING > echo('foo'); // foo > > var_dump(is_callable('isset')); // bool(false) > var_dump(isset(1)); // E_ERROR By itself the idea looks good and useful - but There is an issue: Those language constructs have different semantics from functions. On the one side there a simple difference which can more or less be ignored - like the fact that "echo" has no return value and might be called without parentheses. But also more complex ones: > var_dump(array_filter([0, FALSE, NULL], 'isset')); // [0, FALSE] The argument for isset is not sent via the regular parameter stack but directly as operands to the opcode. This is a key part to the trick on how it works for not producing a notice about undeclared variables and not creating it as userland emulations would. So let's assume we allow this then we must allow this simple code: $c = 'isset'; $c($foo); Now the opcode generated by the compiler here won't know what $c is in the second line (yes, yes, in this case an optimizer could figure it out) and will produce opcode which tries to fetch $foo on the argument stack. Now we could fix this in the executor by doing a string comparison on the function name and - oh wait - we'll already have messed with a variable which shouldn't be there ... So, unfortunately no, language constructs have different semantics which we can't emulate inside function semantics (well ok, it is software, so it is thinkable .. but nobody,yet, came up with a robust patch which doesn't cause maintenance *and* performance penalty) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php