# RC1 - Thread: https://externals.io/message/7552 - Original archive: https://news-web.php.net/php.internals/7552 - Started by Zeev Suraski on 2004-02-04T18:20:47+00:00 - Messages: 26 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/7552.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #7552 — Zeev Suraski — 2004-02-04T18:20:47+00:00 URL: https://externals.io/message/7552#7552 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 --- ## #7553 — Sterling Hughes — 2004-02-04T18:25:15+00:00 URL: https://externals.io/message/7552#7553 · In reply to: #7552 > 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 --- ## #7555 — George Schlossnagle — 2004-02-04T18:32:18+00:00 URL: https://externals.io/message/7552#7555 · In reply to: #7552 > > (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 --- ## #7557 — Adam Maccabee Trachtenberg — 2004-02-04T18:36:30+00:00 URL: https://externals.io/message/7552#7557 · In reply to: #7552 > 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! --- ## #7558 — John Coggeshall — 2004-02-04T18:38:22+00:00 URL: https://externals.io/message/7552#7558 · In reply to: #7557 > > […] > +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/ -=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~= --- ## #7559 — Ilia Alshanetsky — 2004-02-04T18:45:50+00:00 URL: https://externals.io/message/7552#7559 · In reply to: #7552 > (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 --- ## #7562 — Pierre-Alain Joye — 2004-02-04T18:55:00+00:00 URL: https://externals.io/message/7552#7562 · In reply to: #7552 On Wed, 04 Feb 2004 20:20:47 +0200 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. 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 --- ## #7563 — Wez Furlong — 2004-02-04T19:16:46+00:00 URL: https://externals.io/message/7552#7563 · In reply to: #7552 > 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. --- ## #7564 — Andi Gutmans — 2004-02-04T19:30:06+00:00 URL: https://externals.io/message/7552#7564 · In reply to: #7552 At 07:55 PM 2/4/2004 +0100, Pierre-Alain Joye wrote: > > […] > >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 --- ## #7570 — Joe Estock — 2004-02-04T19:33:24+00:00 URL: https://externals.io/message/7552#7570 · In reply to: #7552 > 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) --- ## #7565 — Sterling Hughes — 2004-02-04T19:33:31+00:00 URL: https://externals.io/message/7552#7565 · In reply to: #7564 > > […] > > 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 > > -- > > > -- "Reductionists like to take things apart. The rest of us are just trying to get it together." - Larry Wall, Programming Perl, 3rd Edition --- ## #7567 — Sara Golemon — 2004-02-04T19:39:45+00:00 URL: https://externals.io/message/7552#7567 · In reply to: #7553 > > […] value - > > […] value > > […] > > 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 --- ## #7572 — Pierre-Alain Joye — 2004-02-04T19:53:57+00:00 URL: https://externals.io/message/7552#7572 · In reply to: #7559 On Wed, 4 Feb 2004 13:45:50 -0500 ilia@prohost.org (Ilia Alshanetsky) wrote: > > […] > > +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 --- ## #7573 — Zeev Suraski — 2004-02-04T20:11:33+00:00 URL: https://externals.io/message/7552#7573 · In reply to: #7552 At 22:12 04/02/2004, Steph wrote: > > […] > >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 --- ## #7571 — Steph — 2004-02-04T20:12:44+00:00 URL: https://externals.io/message/7552#7571 · In reply to: #7552 > (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? --- ## #7576 — Lukas Smith — 2004-02-04T20:15:45+00:00 URL: https://externals.io/message/7552#7576 · In reply to: #7573 Zeev Suraski wrote: > At 22:12 04/02/2004, Steph wrote: > > > […] > > > 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 --- ## #7575 — Petras Kudaras — 2004-02-04T20:16:04+00:00 URL: https://externals.io/message/7552#7575 · In reply to: #7573 Zeev Suraski wrote: > At 22:12 04/02/2004, Steph wrote: > > > […] > > 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 --- ## #7579 — Adam Bregenzer — 2004-02-04T20:42:23+00:00 URL: https://externals.io/message/7552#7579 · In reply to: #7573 > At 22:12 04/02/2004, Steph wrote: > > > […] > > 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/ --- ## #7580 — Marcus Boerger — 2004-02-04T20:53:16+00:00 URL: https://externals.io/message/7552#7580 · In reply to: #7552 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 --- ## #7582 — Andi Gutmans — 2004-02-04T21:15:35+00:00 URL: https://externals.io/message/7552#7582 · In reply to: #7552 At 09:53 PM 2/4/2004 +0100, Marcus Boerger wrote: >Hello Zeev, > >Wednesday, February 4, 2004, 7:20:47 PM, you wrote: > > > […] > > > […] > >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... > > […] > > > […] > > > […] > >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? > > […] > >+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 --- ## #7583 — Marcus Boerger — 2004-02-04T21:19:49+00:00 URL: https://externals.io/message/7552#7583 · In reply to: #7582 Hello Andi, Wednesday, February 4, 2004, 10:15:35 PM, you wrote: > At 09:53 PM 2/4/2004 +0100, Marcus Boerger wrote: > > […] > 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... > > […] > 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? > > […] > 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 --- ## #7584 — Andrei Zmievski — 2004-02-04T21:37:14+00:00 URL: https://externals.io/message/7552#7584 · In reply to: #7552 > (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 --- ## #7587 — Andi Gutmans — 2004-02-04T21:50:12+00:00 URL: https://externals.io/message/7552#7587 · In reply to: #7552 At 01:37 PM 2/4/2004 -0800, Andrei Zmievski wrote: > > > […] > >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 --- ## #7650 — Derick Rethans — 2004-02-08T20:53:03+00:00 URL: https://externals.io/message/7552#7650 · In reply to: #7573 > At 22:12 04/02/2004, Steph wrote: > > > […] > > 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 --- ## #7654 — Jon Parise — 2004-02-09T01:57:07+00:00 URL: https://externals.io/message/7552#7654 · In reply to: #7650 > > […] > > 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/) --- Next page: https://externals.io/message/7552.md?page=2