>> 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
hermanrad...@gmail.com | http://hermanradtke.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
