Everything

php

Re: database driver: no more rows

php.internals

Ilia A.

22 years ago

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I wouldn't mind such a change myself, however what about all the installations
where people do while (*fetch_row() !== false) ?

Ilia
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE/lrviLKekh381/CERAigRAJ0fRN4pB7YotuUscTQPZIHalgJcaACfel/2
12EFNHs3rQT+/C7w02mDxGs=
=RvvP
-----END PGP SIGNATURE-----

Lukas Smith

22 years ago

> From: Ilia Alshanetsky [mailto:ilia@prohost.org]
> Sent: Wednesday, October 22, 2003 7:18 PM
> To: Lukas Smith; 'PHP Development'
> Subject: Re: [PHP-DEV] database driver: no more rows
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I wouldn't mind such a change myself, however what about all the
> installations
> where people do while (*fetch_row() !== false) ?

Yeah ... php5 would be a good time to make this change.
I don't assume that a lot of people will actually do !== since in those
methods you either get an array or false ..

Regards,
Lukas

Ard Biesheuvel

22 years ago

>>I wouldn't mind such a change myself, however what about all the
>>installations
>>where people do while (*fetch_row() !== false) ?

Wouldn't it be a lot easier to do it the other way around ?
I mean, the semantics of returning false when a fetch cannot be executed
because aren't any rows left is perfectly clear, and returning NULL when
the result cannot be determined (because of an error) is also better
than returning any other value (like 'false').

This would also be easier to carry out while maintaining BC.

--
Ard

Lukas Smith

22 years ago

> From: Ard Biesheuvel [mailto:abies@php.net]
> Sent: Wednesday, October 22, 2003 7:56 PM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] database driver: no more rows
>
> >>I wouldn't mind such a change myself, however what about all the
> >>installations
> >>where people do while (*fetch_row() !== false) ?
>
> Wouldn't it be a lot easier to do it the other way around ?
> I mean, the semantics of returning false when a fetch cannot be executed
> because aren't any rows left is perfectly clear, and returning NULL when
> the result cannot be determined (because of an error) is also better
> than returning any other value (like 'false').
>
> This would also be easier to carry out while maintaining BC.

Err .. I don't agree.
Null means no data
False means error.

Regards,
Lukas

Ard Biesheuvel

22 years ago

> 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.

--
Ard

Derick Rethans

22 years ago

On Wed, 22 Oct 2003, 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.

I think so too, but I wonder how much this is going to break :)

Derick

--
"Interpreting what the GPL actually means is a job best left to those
that read the future by examining animal entrails."
-------------------------------------------------------------------------
Derick Rethans                                 http://derickrethans.nl/
International PHP Magazine                          http://php-mag.net/
-------------------------------------------------------------------------

Andi Gutmans

22 years ago

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

Lukas Smith

22 years ago

> From: Andi Gutmans [mailto:andi@zend.com]
> Sent: Wednesday, October 22, 2003 11:58 PM

> 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.

Not even in php5?

Regards,
Lukas

Andi Gutmans

22 years ago

At 12:00 AM 10/23/2003 +0200, Lukas Smith wrote:

> > From: Andi Gutmans [mailto:andi@zend.com]
> > Sent: Wednesday, October 22, 2003 11:58 PM
>
> > 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.
>
>Not even in php5?

Nope. It should be as easy as possible for people to migrate from PHP 4 to
PHP 5, and this change isn't one of those blow up in your face things.
It'll probably add all sorts of subtle bugs which are hard to find to
existing applications.
Anyway, I am hoping for no more major changes after I get beta 2 out of the
door next week except for bug fixes and adapting extensions to ZE2.

Andi