Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86604
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.176 as permitted sender)
MIME-Version: 1.0
Sender: are.you.winning@gmail.com
In-Reply-To: <557A1B52.1050501@gmail.com>
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>
	<557A1B52.1050501@gmail.com>
Date: Fri, 12 Jun 2015 01:36:26 +0100
Message-ID: <CAGAGxba51_uOYg1USvp9A=Yj8KsdE2P_-TT=_BtaKDvn-WhqMg@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d044280665c12930518474c6b
Subject: Re: [PHP-DEV] Array dereferencing of scalars
From: cw@daverandom.com (Chris Wright)

--f46d044280665c12930518474c6b
Content-Type: text/plain; charset=UTF-8

On 12 June 2015 at 00:35, Rowan Collins <rowan.collins@gmail.com> wrote:

> 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.
>

+1

If anything is to be done, then this should be it - properly abstract the
underlying structures so that the lexical/conventional limitations on
symbol naming are also imposed by mechanisms that let userland directly
manipulate the names of symbols (define(), class_alias() etc).


>
> 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]
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--f46d044280665c12930518474c6b--