Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86600
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.65 as permitted sender)
MIME-Version: 1.0
Sender: are.you.winning@gmail.com
In-Reply-To: <55794DE2.2080602@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>
Date: Thu, 11 Jun 2015 21:22:06 +0100
Message-ID: <CAGAGxba3JnH8D4yorS2qU_biJaSwOdgV7Nv3UyHKqbVZBnRCRw@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d04428066cae357051843be0f
Subject: Re: [PHP-DEV] Array dereferencing of scalars
From: cw@daverandom.com (Chris Wright)

--f46d04428066cae357051843be0f
Content-Type: text/plain; charset=UTF-8

On 11 June 2015 at 09:59, Rowan Collins <rowan.collins@gmail.com> wrote:

> Yasuo Ohgaki wrote on 11/06/2015 00:50:
>
>> If PHP should return NULL always against NULL variables, we may be better
>> to
>> reconsider these behavior.
>>
>> [yohgaki@dev Download]$ php
>> <?php
>> $v = NULL;
>> $$v;
>>
>>
>> PHP Notice:  Undefined variable:  in - on line 3
>>
>
> This is not complaining that $v is NULL, it is warning you the same as if
> you wrote $v = 'some_name_you_never_assigned_to'; $$v;
>
> Somewhat surprisingly, you can actually assign to the variable whose name
> is NULL: http://3v4l.org/5pXJg


This is actually just converting $v to a string and using this as the
variable name to look up in the symbol table: http://3v4l.org/Z1fWs
(obvious I suppose, just to clarify)


>
>
>  [yohgaki@dev Download]$ php
>> <?php
>> $v = NULL;
>> $v();
>>
>> PHP Fatal error:  Uncaught EngineException: Function name must be a string
>> in -:3
>> Stack trace:
>> #0 {main}
>>    thrown in - on line 3
>>
>
> This one has given a different message because of it being a non-string
> value, but would be equally fatal if you tried to call any undefined
> function. Would coercing NULL to an imaginary function which returns NULL
> actually be useful for anything?
>
>  I don't care much whether these yield NULL always or raise
>> error/exception,
>> but there should be consistency.
>>
>
> I see no reason why these cases need to be consistent, just because they
> both involve NULLs. It's all about the action you invoke, not just the
> value something's interpreted as.


I think what Yasuo is saying is that the function symbol lookup has a type
check and an early bail-out if the type doesn't make sense - even though in
theory the same string cast behaviour could be applied to dynamic function
calls.

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).


>
>
> --
> Rowan Collins
> [IMSoP]
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--f46d04428066cae357051843be0f--