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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
