[RFC] Allow non-variable arguments to empty() and isset() View as Markdown

I just can't help feeling that it is the wrong use of both. If the function
is returning a value, then it's returning a value that needs to be used
somewhere so the work flow handles that. If the function returns nothing
instead that just seems wrong and needs to be handled better. I'm used to
getting back 'false' if the function failed and just check for that so why
would there be any logical reason for using isset or empty to check a
function return?

Use case:

// Function definition:
function getFriends()
{
   // SQL SELECT or Fetching from XML or Fetching from LDAP or ...
   return $resultsAsArray;
}

// Looping on results:
foreach ( getFriends() as $friend )
{
   echo $friend["name"], "\n";
}

// Case where the results are actually not iterated:
$amIAssocial = empty( getFriends() );

This is the exact same thing:
$amIAssocial = !getFriends();

Earlier, I sent this to Lester only:
Most people don't realize that an empty array is already falsy so they
feel the need to use empty. That is the only use-case the RFC gives
for making this change. From the RFC: "For example if func() is
expected to return an array, it feels more natural to verify it's
emptiness using empty() instead of !."

Herman Radtke
hermanradtke@gmail.com | http://hermanradtke.com

Patrick ALLAERT wrote:

2012/5/3 Lester Cainelester@lsces.co.uk:

Anthony Ferrara wrote:

I voted for the ability to use an expression for isset() as well,
since I agree with Ferenc, it's a matter of consistency. Sure, the
use-case for isset() is definitely weaker than for empty(), but at the
same token they are definitely related...

I just can't help feeling that it is the wrong use of both. If the function
is returning a value, then it's returning a value that needs to be used
somewhere so the work flow handles that. If the function returns nothing
instead that just seems wrong and needs to be handled better. I'm used to
getting back 'false' if the function failed and just check for that so why
would there be any logical reason for using isset or empty to check a
function return?

Use case:

// Function definition:
function getFriends()
{
// SQL SELECT or Fetching from XML or Fetching from LDAP or ...
return $resultsAsArray;
}

// Looping on results:
foreach ( getFriends() as $friend )
{
echo $friend["name"], "\n";
}

// Case where the results are actually not iterated:
$amIAssocial = empty( getFriends() );

1. It it not wrong to return "nothing", like empty sets (empty
   arrays), it is a valid case.
2. Returning "false" in the case there is no "results" would be a bad
   idea: not only you would have to put a condition in the function
   definition, but you would also require all iterations (e.g. foreach)
   to be encapsulated in a condition statement to prevent looping on
   "false".

OK I'm just so used to
if( $rs = $this->mDb->query( $query, $bindVars ) ) {
while( $row = $rs->fetchRow() ) {
}
}

So I can't see where 'empty( $rs->fetchRow() )' would fit into the work flow ...

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

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