Re: [RFC] Allow non-variable arguments to empty() and isset()

From: Date: Fri, 04 May 2012 21:24:02 +0000
Subject: Re: [RFC] Allow non-variable arguments to empty() and isset()
References: 1 2 3 4 5 6 7 8 9 10  Groups: php.internals 
Request: Send a blank email to internals+get-60453@lists.php.net to get a copy of this message
> > > 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. > > then maybe you should open a separate rfc and thread for that. btw. $foo = null; doesn't equals/aliases unset($foo); only isset() written in a way so that it checks the existence of the variable AND if it exists then checks that it's value isn't null. maybe this isn't nice for a newcommer to the language, but it is how isset works for a pretty long time now, and changing it would be a major BC break.. not impossible, but that would definitively deserve a separate RFC and discussion. -- Ferenc Kovács @Tyr43l - http://tyrael.hu

« previous php.internals (#60453) next »