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