On Sep 14, 2015, at 13:23, Stanislav Malyshev <smalys...@gmail.com> wrote: > > No. There's no reason for null to exist if isset returns true on null. > If one doesn't understand that, one should not be using null at all.
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.
Programmers have been using null like this for decades, e.g., C strings. It’s
also quite common in databases, where, at least with MySQL, null happens to
translate directly to PHP null when data are queried. And frankly, I see
nothing wrong with recognizing that a variable exists in the symbol table but
has no real value versus one that doesn’t even exist. It’s like the difference
between having a car in your garage that is out of gas versus not having a car
at all.
And again, PHP itself clearly distinguishes the two states everywhere but in
isset() and empty(). IMHO, isset() and empty() are both misguided (beyond the
null problem) because they attribute meaning to certain values of user land
data, and they bundle several checks together. And they do all that without any
domain knowledge controlling what values are or are not valid. If I’m counting
eggs in my basket, zero is most definitely a valid value, while it’s not if I’m
looking at the weight of a specific egg. PHP shouldn’t be making that decision
for me in blanket form. Yet, that’s exactly what these functions do. As I said,
they’re misguided, right up there with register_globals. (They lead to similar
security bugs, too.)
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
If a variable that’s declared yet defined as null can’t “exist” as decided by
isset(), why can an array element that’s declared yet defined as null “exist”
as decided by array_key_exists()? Is the symbol table really that different
from an array? It gets weirder yet where the two start to overlap in user land:
$foo = null;
var_dump(isset($foo)); //false
var_dump(array_key_exists('foo', $GLOBALS)); //true
$array = ['foo' => null];
$bar = null;
extract($array);
print_r(get_defined_vars()); //now have both $foo and $bar in scope
I don’t understand how anyone can see this as being consistent and
self-explanatory, especially if we assume the words ‘exists’ and ‘set’ to have
their traditional programming meanings (‘set’ meaning to assign a value and
‘exists’ meaning there’s an in-scope entry with the given name in the symbol
table).
--
Bob W.
signature.asc
Description: Message signed with OpenPGP using GPGMail
