Lester Caine wrote on 23/09/2015 11:28:
Yes from one point of view the problem is not with is_null() and I can agree with that. The problem is that one can't establish that a call to is_null() is going to access a valid variable while only working in the simple procedural layer.
You can't establish that a call to any function is going to access a valid variable (other than the way Michael mentioned). It really has nothing to do with is_null(), and therefore with the notices that is_null() emits.
exists() -> empty() or is_null() answers all cases and isset() is redundant but for BC reasons can't be removed.
Lots of functions are redundant in that they can be built using other functions. I don't see "if ( exists($foo) && ! is_null($foo) )" as an improvement over "if ( isset($foo) )" for the extremely common case where you don't want or need any distinction between the two states, though.
Using isset() in place of exists() is NOT a valid substitution since one can't then call is_null() KNOWING that the variable does exist.
I think you're flogging a dead horse here. We all agree that isset() does not check for variable existence.
Also, calling both isset() and is_null() on the same variable is entirely pointless, because they both make exactly the same check. "if ( isset($foo) && is_null($foo) )" can be simplified to "if ( false )".
we have hopefully established that the null state is a natural result of interaction with a database
Indeed, I have never disputed that. A non-existent variable, however, is not something I've ever come across in a database context - it would seem to require a result set having rows with different numbers of columns.
Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
