Re: Array dereferencing of scalars

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