Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86603
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.66 as permitted sender)
Message-ID: <557A1B52.1050501@gmail.com>
Date: Fri, 12 Jun 2015 00:35:46 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: PHP Internals List <internals@lists.php.net>
References: <5576051A.3040800@gmx.de>	<55760771.6020802@gmail.com>	<CAGa2bXaknp0sNwk0JqfUPhURToazTfS40cy9ycY09XJT7AeaCw@mail.gmail.com>	<778F345F9918474AB8CAAB03082ECBF7@pc1>	<CAGa2bXZQb3UooF+cZJ9jKv0uVLFZSgcN=xoE6mYLG8UDZqc_Qg@mail.gmail.com>	<5577DEE4.8030205@gmail.com>	<CAF+90c_1s+qGd9UwOMK7OutRw8M0SZzsseQXa_53z0nh0s_Fxw@mail.gmail.com>	<CAGa2bXbi3DCj6YwoLxDxe2+7mjShHgm1jqqP=ABcVUHiQqErxw@mail.gmail.com>	<CAGa2bXYVMe3DCcjgdFEzU6e7-JjpoLQmsJRDqrBZM8MSCcM5tg@mail.gmail.com>	<55794DE2.2080602@gmail.com> <CAGAGxba3JnH8D4yorS2qU_biJaSwOdgV7Nv3UyHKqbVZBnRCRw@mail.gmail.com>
In-Reply-To: <CAGAGxba3JnH8D4yorS2qU_biJaSwOdgV7Nv3UyHKqbVZBnRCRw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Array dereferencing of scalars
From: rowan.collins@gmail.com (Rowan Collins)

On 11/06/2015 21:22, Chris Wright wrote:
> I'm inclined to agree that we should have consistency here, and that 
> the current behaviour in a function context is the correct one. A 
> couple of (IMO) good arguments for this:
>
> - The function behaviour gives a more explanatory and useful error message
> - This is definitely a programming error, there is no valid reason to 
> use NULL as a variable name in this manner. It amounts to what 
> many/most other languages would consider to be a "null pointer 
> exception" or equivalent, and the more useful error message may help 
> track down the error quicker (one might look for a case where the 
> empty string was assigned, instead of looking for a case where it may 
> be NULL).

Well, if you were to model it precisely on the function case, the 
*consistent* behaviour would be to error on any non-string value (e.g. 
$v = 42; $$v;) but not a string which is an illegal variable name ($v = 
'42'; $v(); just complains that function 42 doesn't exist, not that it 
never could).

A more useful approach would perhaps be to look at what should be a 
valid function name, and what should be a valid variable name, and throw 
an error if dynamic access is used to by-pass either restriction.

For instance, this doesn't currently complain about the fact that @ is 
clearly nonsensical as either a function or a variable:

$foo = '@';
var_dump($$foo);
$foo();

And nor does the empty string, which seems no less obvious a bug than a 
NULL:

$foo = '';
var_dump($$foo);
$foo();


-- 
Rowan Collins
[IMSoP]