Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86632
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.172 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAGAGxba51_uOYg1USvp9A=Yj8KsdE2P_-TT=_BtaKDvn-WhqMg@mail.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> <CAGAGxba51_uOYg1USvp9A=Yj8KsdE2P_-TT=_BtaKDvn-WhqMg@mail.gmail.com>
Date: Sun, 14 Jun 2015 12:35:04 +0900
Message-ID: <CAGa2bXY6UibD8J6-fcU1cMzwu4h+6HeLQNfaq4kXgmf9E6APUw@mail.gmail.com>
To: Chris Wright <cw@daverandom.com>
Cc: Rowan Collins <rowan.collins@gmail.com>, PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1137ccec50fbf805187209c3
Subject: Re: [PHP-DEV] Array dereferencing of scalars
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a1137ccec50fbf805187209c3
Content-Type: text/plain; charset=UTF-8

Hi all,

On Fri, Jun 12, 2015 at 9:36 AM, Chris Wright <cw@daverandom.com> wrote:

> 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).


+1
It sounds good change to spot possible bugs.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a1137ccec50fbf805187209c3--