Re: PHP 7.1 - Address PHPSadness #28?

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]