RC1

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

(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

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!

(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

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

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.

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

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)

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

(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?

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

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

(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

At 01:37 PM 2/4/2004 -0800, Andrei Zmievski 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