Re: Array dereferencing of scalars

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]