# What should be in 5.3? - Thread: https://externals.io/message/31930 - Original archive: https://news-web.php.net/php.internals/31930 - Started by Lukas Kahwe Smith on 2007-08-27T09:30:22+00:00 - Messages: 20 - 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 --- ## #31930 — Lukas Kahwe Smith — 2007-08-27T09:30:22+00:00 URL: https://externals.io/message/31930#31930 Hi, In the spirit of forwards compabitility I think the 5.3 release will we very important regardless if we keep or remove the unicode switch in PHP6. From my POV 5.1 and 5.2 have mainly covered stability and performance improvements on top of the addition of several important extensions like PDO, Json etc. In terms of changes to the actual language the main thing that sticks in my head where things like `E_STRICT` and is_a vs. instanceOf. So now with 5.3 we might want to look ahead towards PHP6 and make sure that we add whatever makes sense to have in 5.x that will ease the life for people writing forward compatible code for PHP6. It might also be a chance to revisit the question of how we want to approach strictness and deprecation. Forward compatibility: - binary cast - namespaces - ... Strictness: - What is our philisophy, is OO more strict than procedural or is there no such differntiation? I remember the discussions about dynamic member variables, number incrementing throwing notices inconsistently, signature rewriting. I fear I am opening a can of worms with this one. Although I disagree with the bulk of the decisions on this topic in the past I am not trying to reopen the discussions, I just hope to get a clearer definition on our philosiphie for future discussions Deprecation: - Split of deprecation from `E_STRICT` - Rule for deprecation See the todo wiki for some hints on things currently planned (or that I heard people thinking about planning): http://oss.backendmedia.com/PhP53 http://oss.backendmedia.com/PhP60 regards, Lukas --- ## #31933 — Jani Taskinen — 2007-08-27T10:17:04+00:00 URL: https://externals.io/message/31930#31933 · In reply to: #31930 As an answer to question in subject: HEAD/5.3 should be identical except for the unicode support which is the only thing PHP 6 is about. --Jani --- ## #31934 — Marcus Boerger — 2007-08-27T10:18:53+00:00 URL: https://externals.io/message/31930#31934 · In reply to: #31930 Hello Lukas, I added 'MFH namespace' to the TODO list. Otherwise I am fine. For the given amount of stuff with my name on it I'd need some time though. marcus Monday, August 27, 2007, 11:30:22 AM, you wrote: > Hi, > In the spirit of forwards compabitility I think the 5.3 release will we > very important regardless if we keep or remove the unicode switch in > PHP6. From my POV 5.1 and 5.2 have mainly covered stability and > performance improvements on top of the addition of several important > extensions like PDO, Json etc. > In terms of changes to the actual language the main thing that sticks in > my head where things like `E_STRICT` and is_a vs. instanceOf. So now with > 5.3 we might want to look ahead towards PHP6 and make sure that we add > whatever makes sense to have in 5.x that will ease the life for people > writing forward compatible code for PHP6. It might also be a chance to > revisit the question of how we want to approach strictness and deprecation. > Forward compatibility: > - binary cast > - namespaces > - ... > Strictness: > - What is our philisophy, is OO more strict than procedural or is there > no such differntiation? I remember the discussions about dynamic member > variables, number incrementing throwing notices inconsistently, > signature rewriting. I fear I am opening a can of worms with this one. > Although I disagree with the bulk of the decisions on this topic in the > past I am not trying to reopen the discussions, I just hope to get a > clearer definition on our philosiphie for future discussions > Deprecation: > - Split of deprecation from `E_STRICT` > - Rule for deprecation > See the todo wiki for some hints on things currently planned (or that I > heard people thinking about planning): > http://oss.backendmedia.com/PhP53 > http://oss.backendmedia.com/PhP60 > regards, > Lukas Best regards, Marcus --- ## #31936 — Sebastian Bergmann — 2007-08-27T10:37:08+00:00 URL: https://externals.io/message/31930#31936 · In reply to: #31930 Lukas Kahwe Smith schrieb: > [...] - New Garbage Collector (GSoC) - Late Static Binding -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 --- ## #31940 — Andrei Zmievski — 2007-08-27T17:44:51+00:00 URL: https://externals.io/message/31930#31940 · In reply to: #31936 Don't you thing that a far-reaching thing like garbage collector is best left until a major release? -Andrei http://10fathoms.org/vu - daily photoblog Sebastian Bergmann wrote: > Lukas Kahwe Smith schrieb: > > […] > > - New Garbage Collector (GSoC) > - Late Static Binding --- ## #31943 — Sebastian Bergmann — 2007-08-27T17:51:18+00:00 URL: https://externals.io/message/31930#31943 · In reply to: #31940 Andrei Zmievski schrieb: > Don't you thing that a far-reaching thing like garbage collector is > best left until a major release? It is just a number. We could, of course, also take what is in HEAD minus Unicode and release it, together with Garbage Collector, Late Static Bindings, and some other pending changes as PHP 6 and make PHP 7 the "Unicode Release". :-) -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 --- ## #31950 — Andi Gutmans — 2007-08-27T23:06:19+00:00 URL: https://externals.io/message/31930#31950 · In reply to: #31936 I think we're still far away from a working garbage collector which is production quality. At least last time we were discussing it. This should still remain a PHP 6 item if we can actually make it works in an acceptable way. Andi > -----Original Message----- > From: news [mailto:news@sea.gmane.org] On Behalf Of Sebastian Bergmann > Sent: Monday, August 27, 2007 3:37 AM > To: internals@lists.php.net > Subject: Re: [PHP-DEV] What should be in 5.3? > > Lukas Kahwe Smith schrieb: > > […] > > - New Garbage Collector (GSoC) > - Late Static Binding > > -- > Sebastian Bergmann http://sebastian- > bergmann.de/ > GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B > 5D69 --- ## #31953 — Derick Rethans — 2007-08-28T08:29:49+00:00 URL: https://externals.io/message/31930#31953 · In reply to: #31950 > I think we're still far away from a working garbage collector which is > production quality. At least last time we were discussing it. This > should still remain a PHP 6 item if we can actually make it works in an > acceptable way. Have you checked the latest patch that david send here? He updated quite a bit to address all the issues that were raised as far as I know. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org --- ## #31956 — Cristian Rodriguez — 2007-08-28T21:46:32+00:00 URL: https://externals.io/message/31930#31956 · In reply to: #31950 > I think we're still far away from a working garbage collector which is > production quality. Im sure it has bugs, but last time I tested the "circular" repository it was working really fine and the save of memory was really big ;-) -- http://www.kissofjudas.net/ --- ## #31957 — Andi Gutmans — 2007-08-29T03:32:53+00:00 URL: https://externals.io/message/31930#31957 · In reply to: #31930 Hi all, From my point of view I think we can make a really good PHP 5.3 release pretty quickly as long as we are careful about the scope. There's a lot of good work which is low risk which we can easily roll into it. There are high risk items like garbage collection etc. which I think we should continue working on, etc. but target them more towards PHP 6. Adding such features into a PHP 5.3 branch wouldn't allow us to release that for a long time. I think schedule wise it's not unreasonable to do a pretty feature rich PHP 5.3 beta in November and release in January. I prefer the release-early, release-often mantra and that'll require us to somewhat be careful about the scope and high risk items. The following are some suggestions we (Dmitry, Stas and I) have re: items we had on our lists. We divided them into what we think are must-haves (i.e. don't release without), should-haves (we should try to get these in but they wouldn't be show stoppers for release), and nice to-haves (low priority). Must have: These are ones that we'd really like to be in 5.3 and think should delay 5.3 release if they aren't ready. 1. ICU extension 2. OpenSSL modifications for OpenID 3. Dynamic class access ($class::method) 4. (binary) operator which is the same as (string) 5. remove --enable-fastcgi and family, always enable them 6. __callStatic & friends 7. remove warning for var Should have: These are ones that we'd like to be in 5.3, but if there are problems with them we are ready to go without them and catch up in 5.3.x, 5.4, etc. 1. Unicode extension (normalization, character properties, etc.) 2. Late static binding 3. Namespaces (still needs maturing so that will be the main factor for deciding if in or out) 4. Make memory manager pluggable per-request (simple patch) 5. Synchronize all OO module docs to look the same (PHPDOC team) 6. remove undocumented support for strings in list($a,$b) = "ab" 7. Move arg_info and other C constants from .data to .text (or .rdata) segment 8. Non-parsed heredocs (nowdocs) Nice to have: These are ones that we'd like to have in 5.3, but are not important enough to spend energy on before first two groups are achieved (unless of course somebody has a good working implementation). 1. cookie2 support 2. stat cache for windows/unix 3. mysqlnd 4. goto 5. __construct in interfaces 6. Compiled functions (CFs) and classes in PHP 7. Allow parser to evaluate static expressions (-1, 2+2) in compile-time (it won't work with constants (X+1)) Our 2 cents. Andi > -----Original Message----- > From: Lukas Kahwe Smith [mailto:mls@pooteeweet.org] > Sent: Monday, August 27, 2007 2:30 AM > To: PHP Developers Mailing List > Subject: [PHP-DEV] What should be in 5.3? > > Hi, > > In the spirit of forwards compabitility I think the 5.3 release will we > very important regardless if we keep or remove the unicode switch in > PHP6. From my POV 5.1 and 5.2 have mainly covered stability and > performance improvements on top of the addition of several important > extensions like PDO, Json etc. > > In terms of changes to the actual language the main thing that sticks > in > my head where things like `E_STRICT` and is_a vs. instanceOf. So now with > 5.3 we might want to look ahead towards PHP6 and make sure that we add > whatever makes sense to have in 5.x that will ease the life for people > writing forward compatible code for PHP6. It might also be a chance to > revisit the question of how we want to approach strictness and > deprecation. > > Forward compatibility: > - binary cast > - namespaces > - ... > > Strictness: > - What is our philisophy, is OO more strict than procedural or is there > no such differntiation? I remember the discussions about dynamic member > variables, number incrementing throwing notices inconsistently, > signature rewriting. I fear I am opening a can of worms with this one. > Although I disagree with the bulk of the decisions on this topic in the > past I am not trying to reopen the discussions, I just hope to get a > clearer definition on our philosiphie for future discussions > > Deprecation: > - Split of deprecation from `E_STRICT` > - Rule for deprecation > > See the todo wiki for some hints on things currently planned (or that I > heard people thinking about planning): > > http://oss.backendmedia.com/PhP53 > http://oss.backendmedia.com/PhP60 > > regards, > Lukas --- ## #31958 — Jani Taskinen — 2007-08-29T08:58:15+00:00 URL: https://externals.io/message/31930#31958 · In reply to: #31956 > > > […] > > Im sure it has bugs, but last time I tested the "circular" repository > it was working really fine and the save of memory was really big ;-) Yes, but Andi is desperate to have at least something else than just unicode support in PHP 6. No worries, this will go in 5.3. --Jani --- ## #31960 — Andi Gutmans — 2007-08-29T14:57:09+00:00 URL: https://externals.io/message/31930#31960 · In reply to: #31958 This is based on our experience with making changes in the memory manager (significantly smaller changes than this one) and how long it takes to stabilize them. Andi > -----Original Message----- > From: Jani Taskinen [mailto:jani.taskinen@sci.fi] > Sent: Wednesday, August 29, 2007 1:58 AM > To: Cristian Rodriguez > Cc: internals@lists.php.net > Subject: Re: Re: [PHP-DEV] What should be in 5.3? > > > > […] which > is > > […] repository > > […] > > Yes, but Andi is desperate to have at least something else than just > unicode support in PHP 6. No worries, this will go in 5.3. > > --Jani --- ## #31962 — Sebastian Bergmann — 2007-08-29T15:05:59+00:00 URL: https://externals.io/message/31930#31962 · In reply to: #31960 Andi Gutmans schrieb: > This is based on our experience with making changes in the memory > manager (significantly smaller changes than this one) and how long it > takes to stabilize them. Then we should make sure that the garbage collector goes into HEAD ASAP, should we not? -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 --- ## #31964 — Andi Gutmans — 2007-08-29T15:19:14+00:00 URL: https://externals.io/message/31930#31964 · In reply to: #31962 Sebastian, Just so you guys don't get the wrong idea, I have a garbage collector book sitting on my shelf which I bought 2-3 years ago as I was thinking of implementing this. Unfortunately I hit some issues and edge cases and didn't have enough time to spend on this. So I'm definitely not against a garbage collector. It's something I think would be very good for PHP even if it were optional. I do think though that we need an opportunity to review it, test it & benchmark it. Again, whoever has done work in his life on memory managers knows how sensitive they are. David, do you have a patch against PHP 5.2? For some reason I don't think I got the updated patch although Derick said you sent it out. Thanks, Andi > -----Original Message----- > From: news [mailto:news@sea.gmane.org] On Behalf Of Sebastian Bergmann > Sent: Wednesday, August 29, 2007 8:06 AM > To: internals@lists.php.net > Subject: Re: [PHP-DEV] What should be in 5.3? > > Andi Gutmans schrieb: > > […] it > > […] > > Then we should make sure that the garbage collector goes into HEAD > ASAP, > should we not? > > -- > Sebastian Bergmann http://sebastian- > bergmann.de/ > GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B > 5D69 --- ## #31966 — Sebastian Bergmann — 2007-08-29T15:27:37+00:00 URL: https://externals.io/message/31930#31966 · In reply to: #31964 Andi Gutmans schrieb: > Sebastian, Andi, > I do think though that we need an opportunity to review it, test it & > benchmark it. and this is exactly what I want to faciliate with having David's code merged into HEAD: exposing it to more people for increased testing. David developed his garbage collector in a CVS branch that was copied from PHP_5_2 back when he started. To make the patch smaller, easier to read, and the code review easier I suggest that all his code changes that change direct manipulations of reference counters to the use of the respective macros are committed - they make sense in any case. Cheers, Sebastian -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 --- ## #31967 — Andrey Hristov — 2007-08-29T16:33:21+00:00 URL: https://externals.io/message/31930#31967 · In reply to: #31957 Hi Andi, Andi Gutmans wrote: > Hi all, > > > […] > pretty quickly as long as we are careful about the scope. There's a lot > of good work which is low risk which we can easily roll into it. There > are high risk items like garbage collection etc. which I think we should > continue working on, etc. but target them more towards PHP 6. Adding > such features into a PHP 5.3 branch wouldn't allow us to release that > for a long time. I think schedule wise it's not unreasonable to do a > pretty feature rich PHP 5.3 beta in November and release in January. I > prefer the release-early, release-often mantra and that'll require us to > somewhat be careful about the scope and high risk items. > > The following are some suggestions we (Dmitry, Stas and I) have re: > items we had on our lists. We divided them into what we think are > must-haves (i.e. don't release without), should-haves (we should try to > get these in but they wouldn't be show stoppers for release), and nice > to-haves (low priority). > > Must have: > These are ones that we'd really like to be in 5.3 and think should delay > 5.3 release if they aren't ready. > 1. ICU extension > 2. OpenSSL modifications for OpenID > 3. Dynamic class access ($class::method) > 4. (binary) operator which is the same as (string) > 5. remove --enable-fastcgi and family, always enable them > 6. __callStatic & friends > 7. remove warning for var > > Should have: > These are ones that we'd like to be in 5.3, but if there are problems > with them we are ready to go without them and catch up in 5.3.x, 5.4, > etc. > 1. Unicode extension (normalization, character properties, etc.) > 2. Late static binding > 3. Namespaces (still needs maturing so that will be the main factor > for deciding if in or out) > 4. Make memory manager pluggable per-request (simple patch) > 5. Synchronize all OO module docs to look the same (PHPDOC team) > 6. remove undocumented support for strings in list($a,$b) = "ab" > 7. Move arg_info and other C constants from .data to .text (or > .rdata) segment > 8. Non-parsed heredocs (nowdocs) > > Nice to have: > These are ones that we'd like to have in 5.3, but are not important > enough to spend energy on before first two groups are achieved (unless > of course somebody has a good working implementation). > > 1. cookie2 support > 2. stat cache for windows/unix > 3. mysqlnd speaking of mysqlnd its state is beta. No new features, stabilizing. Currently when running in unicode mode there are about 714 pending execution. There are experimental functions in mysqli, which are skipped for testing. The aim has been always not to lag behind mysqli/libmysql and it's true. Actually mysqli/libmysql lags behing mysqli/mysqlnd as libmysql gets bug-fixes quite slower than mysqlnd does. mysql, mysqli and mysqlnd have gcov level above 88%, as far as I recall. The average for PHP is somewhere above 50%. JFYI, Ulf blogged lately on memory consumption and tuning of mysqlnd. Pretty long, but very good blog entry. We continue to identify bottlenecks and optimize mysqlnd. http://blog.ulf-wendel.de/?p=157 > 4. goto > 5. __construct in interfaces > 6. Compiled functions (CFs) and classes in PHP > 7. Allow parser to evaluate static expressions (-1, 2+2) in > compile-time (it won't work with constants (X+1)) > > Our 2 cents. > Andi > > > […] > we > > […] > with > > […] > there > > […] > member > > […] > the > > […] > I > > […] > Regards, Andrey --- ## #31968 — Stanislav Malyshev — 2007-08-29T17:21:42+00:00 URL: https://externals.io/message/31930#31968 · In reply to: #31962 > Then we should make sure that the garbage collector goes into HEAD ASAP, > should we not? Does anybody uses HEAD in production on a bunch of moderate-to-heavily loaded sites? If not, how does it matter if the patch sits in HEAD or not, one that wishes to test it can do that. I'm not against GC (unless it's slow :) but I don't see why putting it into HEAD matters so much. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #31969 — Rasmus Lerdorf — 2007-08-29T17:32:38+00:00 URL: https://externals.io/message/31930#31969 · In reply to: #31956 Cristian Rodriguez wrote: > > > […] > > > Im sure it has bugs, but last time I tested the "circular" repository > it was working really fine and the save of memory was really big ;-) What sort of script did you save a lot of memory on? It takes some very specific code for you to see noticable savings with this. -Rasmus --- ## #31970 — Pierre — 2007-08-29T17:57:14+00:00 URL: https://externals.io/message/31930#31970 · In reply to: #31968 > > […] > > Does anybody uses HEAD in production on a bunch of moderate-to-heavily > loaded sites? If not, how does it matter if the patch sits in HEAD or > not, one that wishes to test it can do that. > > I'm not against GC (unless it's slow :) but I don't see why putting it > into HEAD matters so much. HEAD is for _development. If we loose the development branch, I cannot imagine any sane to get things done, to get things in nice way :) --Pierre --- ## #31971 — Cristian Rodriguez — 2007-08-29T23:53:03+00:00 URL: https://externals.io/message/31930#31971 · In reply to: #31969 > What sort of script did you save a lot of memory on? It takes some very > specific code for you to see noticable savings with this. I used very specific code otherwise there is no way to test if the particular enhacement work ;) I also used average and big apps in order to check if there was some regression, so far, no problem detected.( note that I did not measure speed, because I care 99% about proper behaviuor and 1% about speed) -- http://www.kissofjudas.net/