Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60439
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 213.123.26.188 cause and error)
Message-ID: <4FA2EDA1.6020605@lsces.co.uk>
Date: Thu, 03 May 2012 21:42:09 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120312 Firefox/11.0 SeaMonkey/2.8
MIME-Version: 1.0
To: PHP internals <internals@lists.php.net>
References: <CAF+90c_N7fhQG_62pEgw_qm2LTDJf=ie0tN1PQVq4XNpMEYcmQ@mail.gmail.com> <CACwt+Jdn7hS8mszbEhhFtthL7hisG-SaXDahzKb9MhY2ZjOWLA@mail.gmail.com> <CABBJUpdAmkEzh9uek2McmdOCkVOWNuHo6kUsFYizGXbRVZ20Dw@mail.gmail.com> <CAEZPtU4VF7y3AJEYmPND-dGuWMrU2NCsXRTBF2p+czazrR33nQ@mail.gmail.com> <CAH-PCH5wtv07jLHE=_HzPAJHb-OivB=FdROcyh7dPJn8Tt1dVw@mail.gmail.com> <CAEZPtU7kv9X0K5kExXOg3nQBqLxXzGq5hc5DRq5dVj7cVdJ55w@mail.gmail.com> <CAAyV7nGi6EvEf_tjFp_chn771+5cn-Lqt6mQSDQn2fD61nsAiw@mail.gmail.com> <4FA23115.9030807@lsces.co.uk> <CACwt+Je6vc4_BCEFaAmEx=xoTYi922kLMNz0B6cxdHYJXUDDXA@mail.gmail.com>
In-Reply-To: <CACwt+Je6vc4_BCEFaAmEx=xoTYi922kLMNz0B6cxdHYJXUDDXA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Allow non-variable arguments to empty() and isset()
From: lester@lsces.co.uk (Lester Caine)

Patrick ALLAERT wrote:
> 2012/5/3 Lester Caine<lester@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