Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68216
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.211.66 cause and error)
To: Daniel Lowrey <rdlowrey@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
In-Reply-To: <CAH8MpnkkzO42k+09qhQ46dH98-tER4foo-snRE1P2umyWkt2_w@mail.gmail.com>
References:
	 <CAH8MpnkkzO42k+09qhQ46dH98-tER4foo-snRE1P2umyWkt2_w@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 19 Jul 2013 20:00:06 +0200
Message-ID: <1374256806.3946.101.camel@guybrush>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Language constructs and callability
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

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