On Fri, May 4, 2012 at 11:48 AM, Richard Lynch <c...@l-i-e.com> wrote:
> On Wed, May 2, 2012 4:43 am, Pierre Joye wrote: > >>> empty() on the other hand, tests if something is empty, and only if > >>> it > >>> is empty. The result of an expression can be empty. > >>> > >> > >> an expression can also have a value of null. > > > > And NULL is empty. No issue here. > > Expressions can also return "", 0, 0.0, "0", array() > > You really think those should all be empty? > Unless I'm missing something here, aren't all those things already considered to be empty?? Here's what the PHP man page for empty() says: The following things are considered to be empty: - *""* (an empty string) - *0* (0 as an integer) - *0.0* (0 as a float) - *"0"* (0 as a string) - *NULL* - *FALSE* - *array()* (an empty array) - *var $var;* (a variable declared, but without a value in a class) If that's the way it already behaves, then why would keeping it that way even be an issue? If an expression returns any of those things, it's empty. 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? The answer seems to be yes as far as I can tell. And if that is the case, then what value is there in allowing it if the return value is always the same no matter what? --Kris
