2012/5/3 Lester Caine <[email protected]>:
> 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".
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
