Robert Williams wrote on 14/09/2015 23:46:
Nonsense. It just means that one isn’t using null the way you do. You’re saying
people shouldn’t be programming to distinguish between
declared-but-defined-null and undeclared. But the fact is, from user land-POV,
null*is* a value, and it’s frequently used where a variable needs to be
defined with a sentinel value that clearly flags the variable as not having an
otherwise valid value. The alternative is to use magic values as sentinels
instead — e.g., 0 or 9999 for an integer, or empty-string for a string — but
that causes all sorts of bugs when those values are only rarely legitimate
versus never legitimate (see: Y2K). Magic values also tend to make code less
readable.
Absolutely. However, in order to need a dynamic check of variable
existence, you must also be using non-existence as a second sentinel
value. You must be saying "if the variable has never been assigned to,
that means state X; if it's been assigned a null value, that means state
Y". My argument is that using undefined variables like that is a bad
choice of sentinel value, and if you need more than one sentinel value
in the first place, you probably need a more complex data type (a
struct-like object with separate state and value properties, for instance).
Incidentally, what’s the difference, philosophically, between these two:
$foo = null;
var_dump(isset($foo)); //false
$foo = [‘bar’ => null];
var_dump(array_key_exists(‘bar’, $foo)); //true
The difference is that when you define $foo, you have chosen that label
directly as part of your source code - just like you'd name a class or
function. You *know* that the variable exists, so the only interesting
question is whether it has a "real" value or a "default" value. In an
explicit declaration like that, you have also chosen 'bar' directly, but
the difference becomes clearer with a more dynamic example:
$foo = [];
$foo[ $key ] = null;
var_dump(array_key_exists(‘bar’, $foo)); // interesting value
Here, the value $key is something which can only be known at run-time;
consequently, you cannot know without running the code whether the array
key will in fact exist. That makes checking for its existence at runtime
a useful ability.
The fact that the internal implementation of the symbol table is similar
to that of an associative array doesn't justify making them identical to
the user.
Regards,
--
Rowan Collins
[IMSoP]
