On Fri, May 4, 2012 at 1:27 PM, Ferenc Kovacs <tyr...@gmail.com> wrote:
> >> I've been following the debate and I'm still a bit unclear as to what the >> benefit would be to allowing non-variables in isset(). I mean, as was >> stated earlier, expressions are neither "set" nor "unset". Furthermore, >> if >> you were to assign a variable to any valid expression (empty or >> otherwise), >> it would be considered "set". Therefore, through simple deductive logic, >> would an expression passed to isset() not, by definition, *always* return >> >> TRUE if the expression itself is syntactically valid? >> > > yeah, this wouldn't be much to think about if isset in php wouldn't handle > null values as not set. > Hmm I'd never really thought about that before. But now that you mention it, that does sound like a problem. Honestly, I can see no value in maintaining a different "standard" for what constitutes a set or not-set variable depending on the function. While I understand Pierre's point that people have used $var = NULL; in the past to unset variables, I don't think we should actually be supporting that. After all, $var = (anything, including nothing) is, by definition, "setting" the variable to something (or nothing). I would analogize this to a printed dictionary. Let's say you look up the word, "glarbofatass". It's not there. So you take out another dictionary and look it up again. There's an entry for it, but the entry says, "This word has no meaning." In the first dictionary, "glarbofatass" is not set. In the second dictionary, "glarbofatass" is set to the state of having no meaning. Nevertheless, it *is* set. I've never thought of setting something to NULL as being *literally *the same thing as unsetting it (though the purpose and end result are mostly the same). If we didn't have an unset() function, I might feel differently about this. But we do, so really I don't see why "= NULL" needs to be an alias for unset(). To be honest, I doubt this would pose any real BC breakage, either, unless someone can point me to an instance where somebody uses "= NULL" to unset a variable and then checks it with isset() later, expecting FALSE. Personally, I would consider "= NULL" == unset() but only as it pertains to isset() to be a bug that should be fixed, not a "feature" that should be preserved. And if we make that change (perhaps target it for PHP 6 since it would nonetheless pose a fundamental logic change, albeit an extremely minor and low-impact one), then this RFC suddenly makes a lot more sense while allowing the scope to be limited to empty() without creating any annoying contradictions. --Kris
