Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:4924
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <5b.405c9ef5.2cc8590a@aol.com>
Date: Wed, 22 Oct 2003 18:04:58 EDT
To: andi@zend.com, internals@lists.php.net
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-----------------------------1066860298"
Subject: Re: [PHP-DEV] database driver: no more rows
From: GPHemsley@aol.com

-------------------------------1066860298
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

In a message dated 10/22/2003 6:00:11 PM Eastern Daylight Time, andi@zend.com 
writes:
At 11:49 PM 10/22/2003 +0200, Ard Biesheuvel wrote:
>>Err .. I don't agree.
>>Null means no data
>>False means error.
>
>Maybe historically (PHP-wise) it does.
>But the way I see it, every fetch() can 'fail' for two reasons: an 
>expected well-defined reason (eof), and an unexpected undefined reason 
>(error). Labelling the well-defined reason as 'false' and the undefined 
>reason as 'null' is really quite defendable.


This isn't something I'd like to see changed. I actually think there are 
probably lots of people who do !== false and we could screw up a lot of 
scripts. I see the advantage of being able to tell the difference but I 
think it's not big enough to change it now.

Andi
Well, this would be my first time contributing to any discussion on this list 
since I joined, but I have a question. 

It was suggested that this be implemented in PHP 5.0.0. Isn't PHP 5 so much 
different than PHP 4 that scripts would have to be somewhat rewritten for it 
anyway? (I'm not saying that PHP 5 is totally different, just different enough.)

I don't think I've had any experince with those functions returning FALSE for 
me, but I think it's more logical that they differentiate between the FALSE 
and the NULL for the reasons stated above.

Gordon Hemsley

-------------------------------1066860298--