Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » RC1 »

RC1

php.internals

Zeev Suraski

22 years ago
Hey, As you must have realized Andi and I have resolved some of the key remaining issues for PHP 5 (and we still are). Due to fact that some of these changes have been pretty big changes we suggest to turn the RC1 we wanted to release at the end of January to a beta 4 by the end of next week. If everything goes smoothly after that, we think RC1 should follow two weeks later. Also, Dmitry has pretty much finished his work on doing a major rewrite of the SOAP extension. We think it would be cool to include it in Beta 4 (it will be feature-frozen by that time) and then go for inclusion in PHP 5. A couple of issues we'd like to decide onbefore we go out with beta 4 are: (a) Failure return value of FETCH_RESOURCE and the default return value - should we change it to be FALSE? Today it's NULL, which is inconsistent with most of the functions in PHP which return FALSE on failure. The downside is that changing it may break scripts that check the return value with === or !== (b) Default inclusion of the SOAP extension Comments welcome, Zeev

Sterling Hughes

22 years ago
> Hey, > > (a) Failure return value of FETCH_RESOURCE and the default return value - > should we change it to be FALSE? Today it's NULL, which is inconsistent > with most of the functions in PHP which return FALSE on failure. The > downside is that changing it may break scripts that check the return value > with === or !== >
Should be NULL, not a boolean FALSE, IMNHO (*). False indicates the given operation was not succesful but everything supplied was in valid boundaries. At least that's how I see it, but PHP is across the board inconsistent in this area, so I see no reason to break BC.
> (b) Default inclusion of the SOAP extension >
+1 -Sterling (*) In My Never Humble Opinion
-- "Reductionists like to take things apart. The rest of us are just trying to get it together." - Larry Wall, Programming Perl, 3rd Edition

Sara Golemon

22 years ago
> > (a) Failure return value of FETCH_RESOURCE and the default return
value -
> > should we change it to be FALSE? Today it's NULL, which is inconsistent > > with most of the functions in PHP which return FALSE on failure. The > > downside is that changing it may break scripts that check the return
value
> > with === or !== > > > > Should be NULL, not a boolean FALSE, IMNHO (*). False indicates the > given operation was not succesful but everything supplied was in valid > boundaries. At least that's how I see it, but PHP is across the board > inconsistent in this area, so I see no reason to break BC. >
-1 for the reasons stated by Sterling above. -Sara

George Schlossnagle

22 years ago
On Feb 4, 2004, at 1:20 PM, Zeev Suraski wrote:
> > (b) Default inclusion of the SOAP extension
I'm +1 for this. It seems to have been making rapid progression and it's an important technology to make easy to access. George

Adam Maccabee Trachtenberg

22 years ago
On Wed, 4 Feb 2004, Zeev Suraski wrote:
> Due to fact that some of these changes have been pretty big changes we > suggest to turn the RC1 we wanted to release at the end of January to a > beta 4 by the end of next week.
I am glad we're doing another beta. There's still more than enough outstanding issues and recent large changes that I think moving straight to RC1 would be bad.
> (b) Default inclusion of the SOAP extension
+1, Definitely. -adam
-- adam@trachtenberg.com author of o'reilly's php cookbook avoid the holiday rush, buy your copy today!

John Coggeshall

22 years ago
On Wed, 2004-02-04 at 13:36, Adam Maccabee Trachtenberg wrote:
> > (b) Default inclusion of the SOAP extension > +1, Definitely.
Ditto on that and B4... However I do question the 2 week timeline between the two, seems a bit short.. John
-- -=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=- John Coggeshall http://www.coggeshall.org/ The PHP Developer's Handbook http://www.php-handbook.com/ -=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-

Ilia A.

22 years ago
> (a) Failure return value of FETCH_RESOURCE and the default return value - > should we change it to be FALSE? Today it's NULL, which is inconsistent > with most of the functions in PHP which return FALSE on failure. The > downside is that changing it may break scripts that check the return value > with === or !==
+1. I think this is a good idea. We've already had bugs where people were using === and !== to determine wether the function had worked or not. Since the resource retrieval (or argument parsing) failed they received unexpected NULL (rather then the documented FALSE) and ended up running an unterminated loop.
> (b) Default inclusion of the SOAP extension
+0. Overall it seems like a good idea. However, I am not sure how stable is SOAP extension after massive revisions Dmitry did and the TODO list still has quite a few entries in it. Do we really want to halt (feature freeze) development at this point? Ilia

Pierre-Alain Joye

22 years ago
On Wed, 4 Feb 2004 13:45:50 -0500 ilia@prohost.org (Ilia Alshanetsky) wrote:
> > (b) Default inclusion of the SOAP extension > > +0. Overall it seems like a good idea. However, I am not sure how > stable is SOAP extension after massive revisions Dmitry did and the > TODO list still has quite a few entries in it. Do we really want to > halt (feature freeze) development at this point?
Add it as experimental? That costs nothing and Dmitry (and the wunderbar pecl guys ;)) will get the time to make it stable (if required, no idea) until a 5.x or 5.0x pierre

Pierre-Alain Joye

22 years ago
On Wed, 04 Feb 2004 20:20:47 +0200 Zeev Suraski <zeev@zend.com> wrote:
> Hey, > > As you must have realized Andi and I have resolved some of the key > remaining issues for PHP 5 (and we still are). > Due to fact that some of these changes have been pretty big changes we > > suggest to turn the RC1 we wanted to release at the end of January to > a beta 4 by the end of next week. > If everything goes smoothly after that, we think RC1 should follow two > weeks later. > Also, Dmitry has pretty much finished his work on doing a > major rewrite of the SOAP extension. We think it would be cool to > include it in Beta 4 (it will be feature-frozen by that time) and then > go for inclusion in PHP 5.
Ah, I thought it was already features frozen since months :)
> A couple of issues we'd like to decide onbefore we go out with beta 4 > are:
One "issue" I would like to put in the light again. The internal ZE 2 APIs. One "issue" here: http://marc.theaimsgroup.com/?l=php-dev&m=107367078904900&w=2 The main problem with a too early beta/rc release is we (well you ;) ) have to be sure that the ZE2 apis works the way it should. And not only from the php side. For the good all php extensions that are not bundled with the php releases (and I'm not thinking only about pecl :) ).
> (b) Default inclusion of the SOAP extension
+1 As a countless opinion, I think 2 weeks is too short to move to a release candidate stage. pierre

Wez Furlong

22 years ago
> Due to fact that some of these changes have been pretty big changes we > suggest to turn the RC1 we wanted to release at the end of January to a > beta 4 by the end of next week. > If everything goes smoothly after that, we think RC1 should follow two > weeks later.
+1 on beta 4. 2 weeks from that point to RC1 might be a little slim, but there's nothing stopping us from having (and we probably should) a series of RC's over a span of 6-8 weeks (maybe longer) from RC1 to help QA those things.
> (b) Default inclusion of the SOAP extension
+1. Stability of soap is reasonably important (but not necessarily a show-stopper). Some good docs will help too. --Wez.

Andi Gutmans

22 years ago
At 07:55 PM 2/4/2004 +0100, Pierre-Alain Joye wrote:
> > A couple of issues we'd like to decide onbefore we go out with beta 4 > > are: > >One "issue" I would like to put in the light again. The internal ZE >2 APIs. One "issue" here: > >http://marc.theaimsgroup.com/?l=php-dev&m=107367078904900&w=2 > >The main problem with a too early beta/rc release is we (well you ;) ) >have to be sure that the ZE2 apis works the way it should. And not only >from the php side. For the good all php extensions that are not bundled >with the php releases (and I'm not thinking only about pecl :) ).
Yeah we looked at it today. It seems to be a bit of a problem. The correct way of doing this is to nuke get_properties() and only use set/get overloading handlers. However, it would mean that extension writers who want foreach() to work would have to implement iterator interface. I'm not quite sure how to go on this one. IMO get_properties() should not be used with non-PHP objects. Andi

Sterling Hughes

22 years ago
> >http://marc.theaimsgroup.com/?l=php-dev&m=107367078904900&w=2 > > > >The main problem with a too early beta/rc release is we (well you ;) ) > >have to be sure that the ZE2 apis works the way it should. And not only > >from the php side. For the good all php extensions that are not bundled > >with the php releases (and I'm not thinking only about pecl :) ). > > Yeah we looked at it today. It seems to be a bit of a problem. The correct > way of doing this is to nuke get_properties() and only use set/get > overloading handlers. However, it would mean that extension writers who > want foreach() to work would have to implement iterator interface. > I'm not quite sure how to go on this one. IMO get_properties() should not > be used with non-PHP objects. >
how would one handle var_dump($obj) then? -sterling
> Andi > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
-- "Reductionists like to take things apart. The rest of us are just trying to get it together." - Larry Wall, Programming Perl, 3rd Edition

Andi Gutmans

22 years ago
At 02:33 PM 2/4/2004 -0500, Sterling Hughes wrote:
> > >http://marc.theaimsgroup.com/?l=php-dev&m=107367078904900&w=2 > > > > > >The main problem with a too early beta/rc release is we (well you ;) ) > > >have to be sure that the ZE2 apis works the way it should. And not only > > >from the php side. For the good all php extensions that are not bundled > > >with the php releases (and I'm not thinking only about pecl :) ). > > > > Yeah we looked at it today. It seems to be a bit of a problem. The correct > > way of doing this is to nuke get_properties() and only use set/get > > overloading handlers. However, it would mean that extension writers who > > want foreach() to work would have to implement iterator interface. > > I'm not quite sure how to go on this one. IMO get_properties() should not > > be used with non-PHP objects. > > > >how would one handle var_dump($obj) then?
Quite a problem, no doubt. The question is, should we expect every overloaded object to be able to give its properties as a hash? (I guess it could return an empty one). Pierre, is the problem only with foreach()? Andi

Pierre-Alain Joye

22 years ago
On Wed, 04 Feb 2004 21:37:11 +0200 andi@zend.com (Andi Gutmans) wrote:
> Quite a problem, no doubt. The question is, should we expect every > overloaded object to be able to give its properties as a hash? (I > guess it could return an empty one). > Pierre, is the problem only with foreach()?
It is a problem (afaics) for: - foreach - reflection - dump functions Btw, in the same topic, are the $foo->bar++; bug is solved too? (sorry, not on my dev box, I can't co). pierre

Pierre-Alain Joye

22 years ago
On Wed, 4 Feb 2004 20:46:57 +0100 paj@pearfr.org (Pierre-Alain Joye) wrote:
> It is a problem (afaics) for: > - foreach > - reflection > - dump functions > > Btw, in the same topic, are the $foo->bar++; bug is solved too?
are the $foo->bar++; and friends (+=, -=, ...) solved too? pierre

Joe Estock

22 years ago
On 2/4/2004 12:20 PM, Zeev Suraski wrote:
> Hey, > > As you must have realized Andi and I have resolved some of the key > remaining issues for PHP 5 (and we still are). > Due to fact that some of these changes have been pretty big changes we > suggest to turn the RC1 we wanted to release at the end of January to a > beta 4 by the end of next week. > If everything goes smoothly after that, we think RC1 should follow two > weeks later. > Also, Dmitry has pretty much finished his work on doing a major rewrite > of the SOAP extension. We think it would be cool to include it in Beta 4 > (it will be feature-frozen by that time) and then go for inclusion in > PHP 5. > > A couple of issues we'd like to decide onbefore we go out with beta 4 are: > > (a) Failure return value of FETCH_RESOURCE and the default return value > - should we change it to be FALSE? Today it's NULL, which is > inconsistent with most of the functions in PHP which return FALSE on > failure. The downside is that changing it may break scripts that check > the return value with === or !== > > (b) Default inclusion of the SOAP extension > > Comments welcome, > > Zeev >
Ok, after many many days of trying to figure out why my posts were not showing up, I finally figured it out
> (b) Default inclusion of the SOAP extension
I would have to +1 this. I have seen extensive use of SOAP + PHP recently and I think that this would be a great addition, however I can see Ilia's point:
> +0. Overall it seems like a good idea. However, I am not sure how > stable is SOAP extension after massive revisions Dmitry did and the > TODO list still has quite a few entries in it. Do we really want to > halt (feature freeze) development at this point?
Even still, I feel that this would be a valuable addition to PHP since many sites/scripts are using SOAP. Joe Estock (a.k.a. guru)

Steph

22 years ago
> (b) Default inclusion of the SOAP extension
That word 'default' kinda muddies the issue - are you suggesting that SOAP is included in distributions, or are you suggesting that it should be enabled by default?

Zeev Suraski

22 years ago
At 22:12 04/02/2004, Steph wrote:
> > (b) Default inclusion of the SOAP extension > >That word 'default' kinda muddies the issue - are you suggesting that SOAP >is included in distributions, or are you suggesting that it should be >enabled by default?
I think we should consider both. Zeev

Petras Kudaras

22 years ago
Zeev Suraski wrote:
> At 22:12 04/02/2004, Steph wrote: > >> > (b) Default inclusion of the SOAP extension >> >> That word 'default' kinda muddies the issue - are you suggesting that >> SOAP >> is included in distributions, or are you suggesting that it should be >> enabled by default? > > I think we should consider both.
I think that enabling the SOAP extension by default is not really necessary (I am a fan of having a clean core with as few extensions enabled as possible), but it would be beneficial to include it in the distribution (provided that a feature freeze is enforced as soon as possible -- i.e. in beta4). It's not that my opinion counts, cause I'm just yet another PHP user...
-- Petras Kudaras aka moxliukas

Lukas Smith

22 years ago
Zeev Suraski wrote:
> At 22:12 04/02/2004, Steph wrote: > >> > (b) Default inclusion of the SOAP extension >> >> That word 'default' kinda muddies the issue - are you suggesting that >> SOAP >> is included in distributions, or are you suggesting that it should be >> enabled by default? > > > I think we should consider both.
I think it would be awesome to have SOAP out of the box. However I do think this shouldn't be rushed (especially since we dont want to break BC). Furthermore its probably a good idea to have ext CS fixed before its enabled by default? regards, Lukas Smith smith@backendmedia.com _______________________________ BackendMedia www.backendmedia.com berlin@backendmedia.com Linn Zwoch Smith GbR Pariser Str. 44 D-10707 Berlin Tel +49 30 83 22 50 00 Fax +49 30 83 22 50 07

Adam Bregenzer

22 years ago
On Wed, 2004-02-04 at 15:11, Zeev Suraski wrote:
> At 22:12 04/02/2004, Steph wrote: > > > > (b) Default inclusion of the SOAP extension > > > >That word 'default' kinda muddies the issue - are you suggesting that SOAP > >is included in distributions, or are you suggesting that it should be > >enabled by default? > > I think we should consider both.
+1 I'm all for including SOAP, I am on the fence about enabling it by default. I would say if it relies on an external library that would otherwise not be needed for a default install then no.
-- Adam Bregenzer adam@bregenzer.net http://adam.bregenzer.net/

Derick Rethans

22 years ago
On Wed, 4 Feb 2004, Zeev Suraski wrote:
> At 22:12 04/02/2004, Steph wrote: > > > > (b) Default inclusion of the SOAP extension > > > >That word 'default' kinda muddies the issue - are you suggesting that SOAP > >is included in distributions, or are you suggesting that it should be > >enabled by default? > > I think we should consider both.
Adding it to the distribution is +1 from me, enabling it by default is a -1 personally as I would turn others on by default before this one. Derick

Jon Parise

22 years ago
On Sun, Feb 08, 2004 at 09:53:03PM +0100, Derick Rethans wrote:
> > > > (b) Default inclusion of the SOAP extension > > > > > >That word 'default' kinda muddies the issue - are you suggesting that SOAP > > >is included in distributions, or are you suggesting that it should be > > >enabled by default? > > > > I think we should consider both. > > Adding it to the distribution is +1 from me, enabling it by default is a > -1 personally as I would turn others on by default before this one.
I agree with Derick.
-- Jon Parise (jon@php.net) :: The PHP Project (http://www.php.net/)

Georg Richter

22 years ago
> Adding it to the distribution is +1 from me, enabling it by default is a > -1 personally as I would turn others on by default before this one.
I agree 100% with Derick Georg

Marcus Börger

22 years ago
Hello Zeev, Wednesday, February 4, 2004, 7:20:47 PM, you wrote:
> Hey,
> As you must have realized Andi and I have resolved some of the key > remaining issues for PHP 5 (and we still are). > Due to fact that some of these changes have been pretty big changes we > suggest to turn the RC1 we wanted to release at the end of January to a > beta 4 by the end of next week. > If everything goes smoothly after that, we think RC1 should follow two > weeks later.
That makes no sense. We still have a lot of open issues so we should calm down a bit and care for creating a working thing instead for the earliest time we could deliver.
> Also, Dmitry has pretty much finished his work on doing a > major rewrite of the SOAP extension. We think it would be cool to include > it in Beta 4 (it will be feature-frozen by that time) and then go for > inclusion in PHP 5.
> A couple of issues we'd like to decide onbefore we go out with beta 4 are:
> (a) Failure return value of FETCH_RESOURCE and the default return value - > should we change it to be FALSE? Today it's NULL, which is inconsistent > with most of the functions in PHP which return FALSE on failure. The > downside is that changing it may break scripts that check the return value > with === or !==
In several places you must now do: $res = func(); if ($res !== NULL && $res !== false) ... plus you have to read lots of documentation when to use what. So i am all for making it a bit consistent. Also most ppl used !== false because most ppl didn't knew the return NULL for out ouf boundaries. So i see nothing to care about what we'd loose.
> (b) Default inclusion of the SOAP extension
+1 prbably not default enabled for 5.0 and we need to change to php_error_docref() and have a look on ZTS which is stupidly solved right now (many unneccesary TSRMLS_FETCH()).
-- Best regards, Marcus mailto:helly@php.net

Andi Gutmans

22 years ago
At 09:53 PM 2/4/2004 +0100, Marcus Boerger wrote:
>Hello Zeev, > >Wednesday, February 4, 2004, 7:20:47 PM, you wrote: > > > Hey, > > > As you must have realized Andi and I have resolved some of the key > > remaining issues for PHP 5 (and we still are). > > Due to fact that some of these changes have been pretty big changes we > > suggest to turn the RC1 we wanted to release at the end of January to a > > beta 4 by the end of next week. > > If everything goes smoothly after that, we think RC1 should follow two > > weeks later. > >That makes no sense. We still have a lot of open issues so we should calm >down a bit and care for creating a working thing instead for the earliest >time we could deliver.
We will try to resolve the important stuff but search the bugs database for PHP 4 problems to see how many problems that has, and it's production for a couple of years :) There is no way to release any version, whether minor nor major without any unresolved issues. That's a dream...
> > Also, Dmitry has pretty much finished his work on doing a > > major rewrite of the SOAP extension. We think it would be cool to include > > it in Beta 4 (it will be feature-frozen by that time) and then go for > > inclusion in PHP 5. > > > A couple of issues we'd like to decide onbefore we go out with beta 4 are: > > > (a) Failure return value of FETCH_RESOURCE and the default return value - > > should we change it to be FALSE? Today it's NULL, which is inconsistent > > with most of the functions in PHP which return FALSE on failure. The > > downside is that changing it may break scripts that check the return value > > with === or !== > >In several places you must now do: > >$res = func(); >if ($res !== NULL && $res !== false) ... > >plus you have to read lots of documentation when to use what. >So i am all for making it a bit consistent. Also most ppl used !== false >because most ppl didn't knew the return NULL for out ouf boundaries. So >i see nothing to care about what we'd loose.
I am +0 on this change. I am not sure though how many scripts this could break. My guess is not very many but it is a possibility. Maybe if we post a patch people here could try and run it on their apps?
> > (b) Default inclusion of the SOAP extension > >+1 prbably not default enabled for 5.0 and we need to change to >php_error_docref() and have a look on ZTS which is stupidly solved >right now (many unneccesary TSRMLS_FETCH()).
The errors and TSRM are minor issues which don't need to be solved (although they could be). Don't forget that TSRMLS_FETCH() is a performance issue and not a functionality issue, and in non-threaded servers which is most PHP production installations, it has no effect whatsoever. What is important is if the functionality is right and if it works (still needs to be proven). In any case, for the meanwhile, it should be marked as experimental. But I think having SOAP in the main distribution will give PHP a big push to fight other technologies and obviously agree with the rest of you that bundling it is a good thing. With the amount of work Dmitry has put into it and will put into it, I'm sure it'll be stable by the time PHP 5.0.0 is released. Andi

Marcus Börger

22 years ago
Hello Andi, Wednesday, February 4, 2004, 10:15:35 PM, you wrote:
> At 09:53 PM 2/4/2004 +0100, Marcus Boerger wrote: >>Hello Zeev, >> >>Wednesday, February 4, 2004, 7:20:47 PM, you wrote: >> >> > Hey, >> >> > As you must have realized Andi and I have resolved some of the key >> > remaining issues for PHP 5 (and we still are). >> > Due to fact that some of these changes have been pretty big changes we >> > suggest to turn the RC1 we wanted to release at the end of January to a >> > beta 4 by the end of next week. >> > If everything goes smoothly after that, we think RC1 should follow two >> > weeks later. >> >>That makes no sense. We still have a lot of open issues so we should calm >>down a bit and care for creating a working thing instead for the earliest >>time we could deliver.
> We will try to resolve the important stuff but search the bugs database for > PHP 4 problems to see how many problems that has, and it's production for a > couple of years :) > There is no way to release any version, whether minor nor major without any > unresolved issues. That's a dream...
>> > Also, Dmitry has pretty much finished his work on doing a >> > major rewrite of the SOAP extension. We think it would be cool to include >> > it in Beta 4 (it will be feature-frozen by that time) and then go for >> > inclusion in PHP 5. >> >> > A couple of issues we'd like to decide onbefore we go out with beta 4 are: >> >> > (a) Failure return value of FETCH_RESOURCE and the default return value - >> > should we change it to be FALSE? Today it's NULL, which is inconsistent >> > with most of the functions in PHP which return FALSE on failure. The >> > downside is that changing it may break scripts that check the return value >> > with === or !== >> >>In several places you must now do: >> >>$res = func(); >>if ($res !== NULL && $res !== false) ... >> >>plus you have to read lots of documentation when to use what. >>So i am all for making it a bit consistent. Also most ppl used !== false >>because most ppl didn't knew the return NULL for out ouf boundaries. So >>i see nothing to care about what we'd loose.
> I am +0 on this change. I am not sure though how many scripts this could > break. My guess is not very many but it is a possibility. Maybe if we post > a patch people here could try and run it on their apps?
>> > (b) Default inclusion of the SOAP extension >> >>+1 prbably not default enabled for 5.0 and we need to change to >>php_error_docref() and have a look on ZTS which is stupidly solved >>right now (many unneccesary TSRMLS_FETCH()).
> The errors and TSRM are minor issues which don't need to be solved > (although they could be). Don't forget that TSRMLS_FETCH() is a performance > issue and not a functionality issue, and in non-threaded servers which is > most PHP production installations, it has no effect whatsoever. > What is important is if the functionality is right and if it works (still > needs to be proven). In any case, for the meanwhile, it should be marked as > experimental. But I think having SOAP in the main distribution will give > PHP a big push to fight other technologies and obviously agree with the > rest of you that bundling it is a good thing. With the amount of work > Dmitry has put into it and will put into it, I'm sure it'll be stable by > the time PHP 5.0.0 is released.
Maybe i'll take a look at those....and yes he does a very good job on it.
-- Best regards, Marcus mailto:helly@php.net

Andrei Zmievski

22 years ago
On Wed, 04 Feb 2004, Zeev Suraski wrote:
> (a) Failure return value of FETCH_RESOURCE and the default return value - > should we change it to be FALSE? Today it's NULL, which is inconsistent > with most of the functions in PHP which return FALSE on failure. The > downside is that changing it may break scripts that check the return value > with === or !==
Given that there is no consistency in whether NULL or FALSE is returned by PHP functions, I'd go with NULL. It's better semantically. - Andrei

Andi Gutmans

22 years ago
At 01:37 PM 2/4/2004 -0800, Andrei Zmievski wrote:
>On Wed, 04 Feb 2004, Zeev Suraski wrote: > > (a) Failure return value of FETCH_RESOURCE and the default return value - > > should we change it to be FALSE? Today it's NULL, which is inconsistent > > with most of the functions in PHP which return FALSE on failure. The > > downside is that changing it may break scripts that check the return value > > with === or !== > >Given that there is no consistency in whether NULL or FALSE is returned >by PHP functions, I'd go with NULL. It's better semantically.
Well according to the figures I posted FALSE definitely wins with 2772 (FALSE) vs. 65 (NULL) so we are not very far from being consistent. Andi