Re: PHP 7.1 - Address PHPSadness #28?

On Sep 14, 2015, at 13:23, Stanislav Malyshev <smalyshev@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.

Attachment: [application/pgp-signature] Message signed with OpenPGP using GPGMail signature.asc