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
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
