Re: [PHP-DEV] towards a 5.3 release
On 03.07.2008, at 02:04, Philip Olson wrote: Essentially the plan is to DocBookify it once 5.3 nears release but today that page requires additional content. Random people add content randomly and unfortunately I'm no longer able to lead this effort so please take over the task of 5.3 upgrade docs procurement. I'll move it to DocBook if/when needed. In other words, to something similar to http://php.net/migration52 Just as an FYI. I am currently learning XSLT so that I can finish the integration of reST [1] as an optional format for wiki pages. Since I will use docbook as an intermediate step from reST to dokuwiki, I should also be able to provide basic docbook support as an optional format in the wiki. This might make it easier to build documents that are intended to be integrated into the manual later on. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] towards a 5.3 release
On 03.07.2008, at 02:08, Alan Knowles wrote: Lukas Kahwe Smith wrote: Aloha, Since Johannes has been stumped (and therefore not as visible as he would have hoped) with work and 5.3 CVS is already filled brim with awesome new features, I have been approached by several people wondering how we can speed up the process. I have always said I am available to play the secretary to the RM, but in order to ensure that developers have a greater chance of having an RM to talk to, Johannes agreed to move me to co-RM status. ..snip.. 3) re2c Rui recently came to the list with notes on the ZE MB feature [7]. This one's pretty critical. #!bang support breaking other code. http://bugs.php.net/bug.php?id=45372 Looks like it would be usefull to have a 'release blocker' flag...? Otherwise it seems reasonably stable here.. I have added the bug to the todo list. I guess thats the best way to track these blocker type bug tickets atm. Also Alan, I am sure I have asked you already if you know anyone that relies on the ZE MB support and if so if they can provide us with a real world example of how they use this feature. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] towards a 5.3 release
On Thu, 3 Jul 2008, Lukas Kahwe Smith wrote: On 03.07.2008, at 02:08, Alan Knowles wrote: Lukas Kahwe Smith wrote: Since Johannes has been stumped (and therefore not as visible as he would have hoped) with work and 5.3 CVS is already filled brim with awesome new features, I have been approached by several people wondering how we can speed up the process. I have always said I am available to play the secretary to the RM, but in order to ensure that developers have a greater chance of having an RM to talk to, Johannes agreed to move me to co-RM status. ..snip.. 3) re2c Rui recently came to the list with notes on the ZE MB feature [7]. This one's pretty critical. #!bang support breaking other code. http://bugs.php.net/bug.php?id=45372 Looks like it would be usefull to have a 'release blocker' flag...? Otherwise it seems reasonably stable here.. I have added the bug to the todo list. I guess thats the best way to track these blocker type bug tickets atm. Actually, this is why we have Critical. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Closures: updated proposal and patch
Hi Lukas, From my point of view the proposed closures concept is very consistent and implementation doesn't complicate the engine at all. The code without closures will work without any changes, but code with closures (instead of eval() and create_function()) will work significant faster as lambda function will be stored in opcode caches. Opcode caches don't even need to be modified to do that. BTW: I see you point of view and it makes sense. It's just pity that we will need to wait for closures additional year(s). Thanks. Dmitry. Lukas Kahwe Smith wrote: On 02.07.2008, at 13:41, Christian Seiler wrote: I've spoken to Dmitry and he said the patch will be committed to HEAD soon. Since both Dmitry and I still want to have it in 5_3 too, we'd want to ask for opinions on this again - especially since after quite a lot of thorough review and discussion on this list basically all the side-effects have been addressed and there are now quite a few tests that ensure the correct behaviour of closures. Also, the patch is now built in a way that the main functionality remains inside zend_closures.c, so any possible not yet encountered bug can be fixed without breaking binary compability. I talked to Johannes about this. It does indeed seem like this feature is in a very solid stage at this point. However the current version of the patch is still young. Also we already have such an insanely long list of new big features, that anything that will take even the slightest focus away on getting this long list rock solid will have to wait until 5.4. Even the most rock solid proposal is bound to have some small issues after all. So as things look atm, closures will have to wait until then. But cool features like closures, traits etc will undoubtedly increase the incentive to get working quickly on 5.4 and this can happen as soon as we have 5.3 out the door and working well for our user base. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] towards a 5.3 release
Etienne Kneuss wrote: 2) late static binding Etienne had some questions recently [5], which were met by criticism by Stas [6]. However all others agreed with the change. So I guess we are solid here too? Yes, the only thing remaining is a tad of love from somebody with ZE karma to commit the patches. Give me the patch and tests for it, I'll probably commit it after review. Thanks. Dmitry. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] towards a 5.3 release
Lukas Kahwe Smith wrote: 2) phar extension I guess we are pretty solid here? We'll need to review the phar before release. It definitely must be in 5.3, but it should be improved, and this improvements may require some changes in ZE. For now packed phpMyAdmin is 4 times slower than unpacked (with and without opcode cache). I'm going to assign next week to ext/phar. Thanks. Dmitry. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_3) / Zend.m4 zend.c zend_compile.c zend_globals.h zend_highlight.c zend_language_scanner.c zend_language_scanner.h zend_language_scanner.l zend_l
On Sun, 29 Jun 2008, Rui Hirokawa wrote:
hirokawa Sun Jun 29 08:21:36 2008 UTC
Modified files: (Branch: PHP_5_3)
/ZendEngine2 Zend.m4 zend.c zend_compile.c zend_globals.h
zend_highlight.c zend_language_scanner.c
zend_language_scanner.h zend_language_scanner.l
zend_language_scanner_defs.h zend_multibyte.h
Log:
implemented again zend-multibyte for PHP 5.3
I found a bug with this, run the attached script with both multi-byte on
and off, and you'll see it.
regards,
Derickpre
?php
echo h3Testing all bytes 0 to 255/h3;
$str = ?php\n;
for ($i = 0; $i 256; $i++ )
{
$str = $str . \$a[$i]=' . str_replace(array(\\, '),array(,
\\'),chr($i)) . ';\n;
}
$str .= // THIS SHOULD NOT SHOW!!!;
file_put_contents('zz.php', $str);
include('zz.php');
var_dump($a);
echo hrh3Testing BOM/h3;
$str = ?php\n;
$str = $str . \$b[]=' . chr(255) . chr(254) . ';\n;
$str = $str . \$b[]=' . chr(254) . chr(255) . ';\n;
$str .= // THIS SHOULD NOT SHOW!!!;
file_put_contents('zzz.php', $str);
include('zzz.php');
var_dump($b);
?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 6 (and forget 5.4) (Was: Re: [PHP-DEV] [RFC] Closures: updated proposal and patch)
On Wed, 2 Jul 2008, Lukas Kahwe Smith wrote: On 02.07.2008, at 13:41, Christian Seiler wrote: So as things look atm, closures will have to wait until then. But cool features like closures, traits etc will undoubtedly increase the incentive to get working quickly on 5.4 and this can happen as soon as we have 5.3 out the door and working well for our user base. Actually, we should forget about 5.4 and focus on 6.0 instead. It has been lingering for waay to long now. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6 (and forget 5.4) (Was: Re: [PHP-DEV] [RFC] Closures: updated proposal and patch)
Derick Rethans wrote: On Wed, 2 Jul 2008, Lukas Kahwe Smith wrote: On 02.07.2008, at 13:41, Christian Seiler wrote: So as things look atm, closures will have to wait until then. But cool features like closures, traits etc will undoubtedly increase the incentive to get working quickly on 5.4 and this can happen as soon as we have 5.3 out the door and working well for our user base. Actually, we should forget about 5.4 and focus on 6.0 instead. It has been lingering for waay to long now. YES PLEASE -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6 (and forget 5.4) (Was: Re: [PHP-DEV] [RFC] Closures: updated proposal and patch)
Absolutely agree. I don't see any reason for 5.4. We don't plan any significant new features. Thanks. Dmitry. Derick Rethans wrote: On Wed, 2 Jul 2008, Lukas Kahwe Smith wrote: On 02.07.2008, at 13:41, Christian Seiler wrote: So as things look atm, closures will have to wait until then. But cool features like closures, traits etc will undoubtedly increase the incentive to get working quickly on 5.4 and this can happen as soon as we have 5.3 out the door and working well for our user base. Actually, we should forget about 5.4 and focus on 6.0 instead. It has been lingering for waay to long now. regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6 (and forget 5.4) (Was: Re: [PHP-DEV] [RFC] Closures: updated proposal and patch)
On 03.07.2008, at 10:34, Dmitry Stogov wrote: Absolutely agree. I don't see any reason for 5.4. We don't plan any significant new features. You guys are scaring me .. I was hoping to evade such discussions. PHP 5.3 is probably the minor version release with the most major changes ever. Mostly because we waited too long to go into release mode. PHP 6 has of course lingered even longer and it really really needs to get out the door ASAP. Now what I would propose is that we go into release mode on PHP 6 as well. Due to the nature of it being a major version bump it will naturally take longer to get completed. Depending on how quickly we move with PHP 5.3, we will then either release a PHP 5.4 with all of the open items before PHP 6 or more or less at the same time. But if we put the burden of being the last planned PHP 5 release onto 5.3, we will have huge issues getting it out the door. So please let us keep 5.4 on the table, but at the same time do everything we can to get PHP 6 onto some sort of release schedule. I have emailed Andrei about this offlist when I saw Derick's email. But I just wanted to send this email as a sort of damage control :) regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6 (and forget 5.4) (Was: Re: [PHP-DEV] [RFC] Closures: updated proposal and patch)
On Jul 3, 2008, at 4:41 AM, Lukas Kahwe Smith wrote: Absolutely agree. I don't see any reason for 5.4. We don't plan any significant new features. You guys are scaring me .. I was hoping to evade such discussions. PHP 5.3 is probably the minor version release with the most major changes ever. Mostly because we waited too long to go into release mode. PHP 6 has of course lingered even longer and it really really needs to get out the door ASAP. Now what I would propose is that we go into release mode on PHP 6 as well. Due to the nature of it being a major version bump it will naturally take longer to get completed. Depending on how quickly we move with PHP 5.3, we will then either release a PHP 5.4 with all of the open items before PHP 6 or more or less at the same time. But if we put the burden of being the last planned PHP 5 release onto 5.3, we will have huge issues getting it out the door. So please let us keep 5.4 on the table, but at the same time do everything we can to get PHP 6 onto some sort of release schedule. I have emailed Andrei about this offlist when I saw Derick's email. But I just wanted to send this email as a sort of damage control :) A loud +1 to this from me. Can we get an RFC into the Wiki on this? -- Gwynne, Daughter of the Code This whole world is an asylum for the incurable. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Namespaces for internal classes
Hello everbody, one thing on my mind is the current naming of our internal classes. I could say the same for our functions but no, I don't have plans to save the universe, saving the world should be enough for now. So I've tried to dig through the ext/spl-package as an example how to implement namespaces for internal classes. Also I did it for SPL now, I would go on further and discuss such changes e.g. for ext/intl. And here is the resulting RFC: http://wiki.php.net/rfc/namespaces-for-internal-classes The RFC is not ready yet but I want to get feedback on it. The integral part is the list of renamings and that's fixed, so you can expect a bit more prose :) Having that for 5.3 seems like a good idea, as we have a) a number of added SPL classes, b) most likely new extensions introducing new classes (ext/intl, ext/phar), c) having it is 5.3 would allow us seemless transistions to newer PHP versions. cu, Lars signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] [RFC] Closures: updated proposal and patch
Hi, 1) The RFC page says that closures pass by value by default. Although it is not stated, am I correct in saying that due to the way resources and objects (and presumably therefore lambdas) are handled they will still have the effect of passing by reference anyway, just as with a function parameter? Yes, of course. :) 2) It is unclear from the RFC if static class closures (I am not fond of that syntax, I grant) are the only ones that won't import $this. Is the suggested detection optimization not included, and therefore it's up to the programmer to avoid dangling references that keep stray classes around? It's up to the programmer for now, static = no $this, no static = $this. 3) Can __invoke() accept parameters, Yes. 4) The ability to reflect and then call a function or method as a closure sounds highly nifty. However, I am unclear on why it is necessary to pass in the $this to use. In that case, wouldn't it make more sense to use ReflectionObject() in the first place so that the $this is implicitly known? Probably. But if we start picking on every detail of the patch until it is absolutely perfect, it will never get committed, not even to HEAD. So I propose that it should be committed to HEAD (as long as there are no major objections) and then worry about tiny details afterwards. 5) There's a couple spelling and grammar errors. :-) Feel free to correct them if you have access to the wiki. Regards, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6 (and forget 5.4)
Lukas Kahwe Smith skrev:
But if we put the burden of being the last planned PHP 5 release onto
5.3, we will have huge issues getting it out the door. So please let us
keep 5.4 on the table, but at the same time do everything we can to get
PHP 6 onto some sort of release schedule.
Let me see if I get this.
PHP 5.4 = 6.0 without Unicode.
PHP 6.0 = 5.4 plus Unicode.
It sounds like PHP 5.4 is actually needed when 6.0 no longer has the
Unicode semantics on/off switch.
FWIW, personally, I need Unicode more than I need namespaces; I need
Unicode more than I need traits; I need Unicode more than I need lambda
and closures. I need Unicode more than I need {$capability_of_choice}.
All of those things are nice, but Unicode is getting *critical*.
Lars Gunther
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_3) /ext/mcrypt mcrypt.c php_mcrypt.h /ext/mcrypt/tests bug35496.phpt bug41252.phpt bug43143.phpt mcrypt_cbc.phpt mcrypt_cbf.phpt mcrypt_decrypt.phpt
On Thu, 3 Jul 2008, Pierre-Alain Joye wrote: pajoyeThu Jul 3 13:50:15 2008 UTC Modified files: (Branch: PHP_5_3) /php-src/ext/mcrypt mcrypt.c php_mcrypt.h /php-src/ext/mcrypt/tests bug35496.phpt bug41252.phpt bug43143.phpt mcrypt_cbc.phpt mcrypt_cbf.phpt mcrypt_decrypt.phpt Log: - fix mcrypt_iv on windows, use urandom equivalent - MFH, code cleaning and reorganisation WTF, you mentioned that you'd be doing this, and I agreed to a patch that you showed for it. You *NEVER* mentioned anything of touching every single line of this code. There is 1. no good reason, 2. you should discuss that with the maintainer and 3. NEVER mix code and whitespace changes. Revert this patch, now. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] towards a 5.3 release
Hello, 3) re2c Rui recently came to the list with notes on the ZE MB feature [7]. @Scott/Marcus: Is this enough for you guys to get this working? @Rui: Is there any chance you can get more people in the japanese (or asian in general) community involved here? I hope that we can have more people as testers. I will disscuss this problem on japanese develoepers mailing list. Derick already found a bug. I will try to fix the bug soon. I hope that PHP developpers in non-asian country also evaluate the zend-multibyte because zend-multibute also support single-byte encodings. Rui -- Rui Hirokawa [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_3) /ext/mcrypt mcrypt.c php_mcrypt.h /ext/mcrypt/tests bug35496.phpt bug41252.phpt bug43143.phpt mcrypt_cbc.phpt mcrypt_cbf.phpt mcrypt_decrypt.phpt
On Thu, Jul 3, 2008 at 4:23 PM, Derick Rethans [EMAIL PROTECTED] wrote: On Thu, 3 Jul 2008, Pierre-Alain Joye wrote: pajoyeThu Jul 3 13:50:15 2008 UTC Modified files: (Branch: PHP_5_3) /php-src/ext/mcrypt mcrypt.c php_mcrypt.h /php-src/ext/mcrypt/tests bug35496.phpt bug41252.phpt bug43143.phpt mcrypt_cbc.phpt mcrypt_cbf.phpt mcrypt_decrypt.phpt Log: - fix mcrypt_iv on windows, use urandom equivalent - MFH, code cleaning and reorganisation WTF, you mentioned that you'd be doing this, and I agreed to a patch that you showed for it. You *NEVER* mentioned anything of touching every single line of this code. There is 1. no good reason, 2. you should discuss that with the maintainer and 3. NEVER mix code and whitespace changes. Revert this patch, now. You gave me your OK to MFH the cleanup code from HEAD. I see no reason to revert this commit now, why do you want me to revert it except for making my work harder? Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Closures: updated proposal and patch
I think given closures is in a pretty fully baked state (we had an exemplary process) the main questions to ask are: a) Assuming we are going through numerous beta and RC cycles for PHP 5.3, do we think that the time it would take for other features like namespaces, garbage collector to be fully tested and stabilize would allow for closures to stabilize too in that same time frame (i.e. would not push out a final release date for PHP 5.3)? b) Are the release managers willing to manage an additional major feature as part of the release process? I am not stating my opinion here because I could go either way although ultimately my bias is not to postpone a feature freeze nor a final release so it's really up to the release managers to decide on (1) and (2). Andi -Original Message- From: Dmitry Stogov [mailto:[EMAIL PROTECTED] Sent: Thursday, July 03, 2008 12:27 AM To: Lukas Kahwe Smith Cc: Christian Seiler; php-dev List Subject: Re: [PHP-DEV] [RFC] Closures: updated proposal and patch Hi Lukas, From my point of view the proposed closures concept is very consistent and implementation doesn't complicate the engine at all. The code without closures will work without any changes, but code with closures (instead of eval() and create_function()) will work significant faster as lambda function will be stored in opcode caches. Opcode caches don't even need to be modified to do that. BTW: I see you point of view and it makes sense. It's just pity that we will need to wait for closures additional year(s). Thanks. Dmitry. Lukas Kahwe Smith wrote: On 02.07.2008, at 13:41, Christian Seiler wrote: I've spoken to Dmitry and he said the patch will be committed to HEAD soon. Since both Dmitry and I still want to have it in 5_3 too, we'd want to ask for opinions on this again - especially since after quite a lot of thorough review and discussion on this list basically all the side-effects have been addressed and there are now quite a few tests that ensure the correct behaviour of closures. Also, the patch is now built in a way that the main functionality remains inside zend_closures.c, so any possible not yet encountered bug can be fixed without breaking binary compability. I talked to Johannes about this. It does indeed seem like this feature is in a very solid stage at this point. However the current version of the patch is still young. Also we already have such an insanely long list of new big features, that anything that will take even the slightest focus away on getting this long list rock solid will have to wait until 5.4. Even the most rock solid proposal is bound to have some small issues after all. So as things look atm, closures will have to wait until then. But cool features like closures, traits etc will undoubtedly increase the incentive to get working quickly on 5.4 and this can happen as soon as we have 5.3 out the door and working well for our user base. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6 (and forget 5.4)
+1 from me - unicode is very very needed indeed.
Normaly on every project I have to deal with 3 languages - english, russian
and latvian - and there is no fun in making advanced html/bbcode parser (not
based on str_replace or preg_replace - it is far more complex than that)
using mb_string functions.
2008/7/3 Keryx Web [EMAIL PROTECTED]:
Lukas Kahwe Smith skrev:
But if we put the burden of being the last planned PHP 5 release onto 5.3,
we will have huge issues getting it out the door. So please let us keep 5.4
on the table, but at the same time do everything we can to get PHP 6 onto
some sort of release schedule.
Let me see if I get this.
PHP 5.4 = 6.0 without Unicode.
PHP 6.0 = 5.4 plus Unicode.
It sounds like PHP 5.4 is actually needed when 6.0 no longer has the
Unicode semantics on/off switch.
FWIW, personally, I need Unicode more than I need namespaces; I need
Unicode more than I need traits; I need Unicode more than I need lambda and
closures. I need Unicode more than I need {$capability_of_choice}. All of
those things are nice, but Unicode is getting *critical*.
Lars Gunther
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Closures: updated proposal and patch
I don't see big problems with closures. The patch is simple and stable. It's main part isolated in zend_closures.c and it doesn't affect other parts of engine. I expect more problems with GC Thanks. Dmitry. Andi Gutmans wrote: I think given closures is in a pretty fully baked state (we had an exemplary process) the main questions to ask are: a) Assuming we are going through numerous beta and RC cycles for PHP 5.3, do we think that the time it would take for other features like namespaces, garbage collector to be fully tested and stabilize would allow for closures to stabilize too in that same time frame (i.e. would not push out a final release date for PHP 5.3)? b) Are the release managers willing to manage an additional major feature as part of the release process? I am not stating my opinion here because I could go either way although ultimately my bias is not to postpone a feature freeze nor a final release so it's really up to the release managers to decide on (1) and (2). Andi -Original Message- From: Dmitry Stogov [mailto:[EMAIL PROTECTED] Sent: Thursday, July 03, 2008 12:27 AM To: Lukas Kahwe Smith Cc: Christian Seiler; php-dev List Subject: Re: [PHP-DEV] [RFC] Closures: updated proposal and patch Hi Lukas, From my point of view the proposed closures concept is very consistent and implementation doesn't complicate the engine at all. The code without closures will work without any changes, but code with closures (instead of eval() and create_function()) will work significant faster as lambda function will be stored in opcode caches. Opcode caches don't even need to be modified to do that. BTW: I see you point of view and it makes sense. It's just pity that we will need to wait for closures additional year(s). Thanks. Dmitry. Lukas Kahwe Smith wrote: On 02.07.2008, at 13:41, Christian Seiler wrote: I've spoken to Dmitry and he said the patch will be committed to HEAD soon. Since both Dmitry and I still want to have it in 5_3 too, we'd want to ask for opinions on this again - especially since after quite a lot of thorough review and discussion on this list basically all the side-effects have been addressed and there are now quite a few tests that ensure the correct behaviour of closures. Also, the patch is now built in a way that the main functionality remains inside zend_closures.c, so any possible not yet encountered bug can be fixed without breaking binary compability. I talked to Johannes about this. It does indeed seem like this feature is in a very solid stage at this point. However the current version of the patch is still young. Also we already have such an insanely long list of new big features, that anything that will take even the slightest focus away on getting this long list rock solid will have to wait until 5.4. Even the most rock solid proposal is bound to have some small issues after all. So as things look atm, closures will have to wait until then. But cool features like closures, traits etc will undoubtedly increase the incentive to get working quickly on 5.4 and this can happen as soon as we have 5.3 out the door and working well for our user base. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6 (and forget 5.4) (Was: Re: [PHP-DEV] [RFC] Closures: updated proposal and patch)
Given the 5.3 is not yet out (even as a Beta) I think discussing 5.4 is way way premature. For now I think 5.3 is close enough to 6 in feature set to not warrant 5.4. I think the effort at this point should be spent on getting 5.3 out and figuring out how to proceed with PHP 6. On 3-Jul-08, at 4:06 AM, Derick Rethans wrote: On Wed, 2 Jul 2008, Lukas Kahwe Smith wrote: On 02.07.2008, at 13:41, Christian Seiler wrote: So as things look atm, closures will have to wait until then. But cool features like closures, traits etc will undoubtedly increase the incentive to get working quickly on 5.4 and this can happen as soon as we have 5.3 out the door and working well for our user base. Actually, we should forget about 5.4 and focus on 6.0 instead. It has been lingering for waay to long now. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Closures: updated proposal and patch
Looking through the closures patch, I would tend to agree. GC has certainly caused us way more headaches in APC-land than closures will, from the looks of it. -Rasmus Dmitry Stogov wrote: I don't see big problems with closures. The patch is simple and stable. It's main part isolated in zend_closures.c and it doesn't affect other parts of engine. I expect more problems with GC Thanks. Dmitry. Andi Gutmans wrote: I think given closures is in a pretty fully baked state (we had an exemplary process) the main questions to ask are: a) Assuming we are going through numerous beta and RC cycles for PHP 5.3, do we think that the time it would take for other features like namespaces, garbage collector to be fully tested and stabilize would allow for closures to stabilize too in that same time frame (i.e. would not push out a final release date for PHP 5.3)? b) Are the release managers willing to manage an additional major feature as part of the release process? I am not stating my opinion here because I could go either way although ultimately my bias is not to postpone a feature freeze nor a final release so it's really up to the release managers to decide on (1) and (2). Andi -Original Message- From: Dmitry Stogov [mailto:[EMAIL PROTECTED] Sent: Thursday, July 03, 2008 12:27 AM To: Lukas Kahwe Smith Cc: Christian Seiler; php-dev List Subject: Re: [PHP-DEV] [RFC] Closures: updated proposal and patch Hi Lukas, From my point of view the proposed closures concept is very consistent and implementation doesn't complicate the engine at all. The code without closures will work without any changes, but code with closures (instead of eval() and create_function()) will work significant faster as lambda function will be stored in opcode caches. Opcode caches don't even need to be modified to do that. BTW: I see you point of view and it makes sense. It's just pity that we will need to wait for closures additional year(s). Thanks. Dmitry. Lukas Kahwe Smith wrote: On 02.07.2008, at 13:41, Christian Seiler wrote: I've spoken to Dmitry and he said the patch will be committed to HEAD soon. Since both Dmitry and I still want to have it in 5_3 too, we'd want to ask for opinions on this again - especially since after quite a lot of thorough review and discussion on this list basically all the side-effects have been addressed and there are now quite a few tests that ensure the correct behaviour of closures. Also, the patch is now built in a way that the main functionality remains inside zend_closures.c, so any possible not yet encountered bug can be fixed without breaking binary compability. I talked to Johannes about this. It does indeed seem like this feature is in a very solid stage at this point. However the current version of the patch is still young. Also we already have such an insanely long list of new big features, that anything that will take even the slightest focus away on getting this long list rock solid will have to wait until 5.4. Even the most rock solid proposal is bound to have some small issues after all. So as things look atm, closures will have to wait until then. But cool features like closures, traits etc will undoubtedly increase the incentive to get working quickly on 5.4 and this can happen as soon as we have 5.3 out the door and working well for our user base. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Closures: updated proposal and patch
On Thu, 03 Jul 2008 11:06:48 +0200, Christian Seiler [EMAIL PROTECTED] wrote: Hi, 1) The RFC page says that closures pass by value by default. Although it is not stated, am I correct in saying that due to the way resources and objects (and presumably therefore lambdas) are handled they will still have the effect of passing by reference anyway, just as with a function parameter? Yes, of course. :) Just making sure. :-) 2) It is unclear from the RFC if static class closures (I am not fond of that syntax, I grant) are the only ones that won't import $this. Is the suggested detection optimization not included, and therefore it's up to the programmer to avoid dangling references that keep stray classes around? It's up to the programmer for now, static = no $this, no static = $this. Hm. I defer to those who understand the guts of the engine on whether that's a good call or not. If left as is then the user docs should be very clear about the potential for memory issues there, since most lambas I suspect will not need a $this, even if they happen to be defined within a method. 3) Can __invoke() accept parameters, Yes. Neato. That should also be included in the user-side docs. 4) The ability to reflect and then call a function or method as a closure sounds highly nifty. However, I am unclear on why it is necessary to pass in the $this to use. In that case, wouldn't it make more sense to use ReflectionObject() in the first place so that the $this is implicitly known? Probably. But if we start picking on every detail of the patch until it is absolutely perfect, it will never get committed, not even to HEAD. So I propose that it should be committed to HEAD (as long as there are no major objections) and then worry about tiny details afterwards. As a rank-and-file PHP developer, I have no major objections remaining that aren't bikeshed questions. :-) (And I certainly understand the desire to get the base committed and polish/extend in follow-up patches, as I am doing so myself on another project.) 5) There's a couple spelling and grammar errors. :-) Feel free to correct them if you have access to the wiki. I do not believe I do. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Namespaces for internal classes
Hey Lars; On Jul 3, 2008, at 4:07 AM, Lars Strojny wrote: one thing on my mind is the current naming of our internal classes. I could say the same for our functions but no, I don't have plans to save the universe, saving the world should be enough for now. So I've tried to dig through the ext/spl-package as an example how to implement namespaces for internal classes. Also I did it for SPL now, I would go on further and discuss such changes e.g. for ext/intl. And here is the resulting RFC: http://wiki.php.net/rfc/namespaces-for-internal-classes The RFC is not ready yet but I want to get feedback on it. The integral part is the list of renamings and that's fixed, so you can expect a bit more prose :) Having that for 5.3 seems like a good idea, as we have a) a number of added SPL classes, b) most likely new extensions introducing new classes (ext/intl, ext/phar), c) having it is 5.3 would allow us seemless transistions to newer PHP versions. +1 on the idea, but I'm not huge on the current naming structure. Here's just a few things that I would change: * Completely bike shedding, but does Recursive need its own level? RecursiveArray reads better than having Array at two different levels to me. * Again, bike shedding, but I like the name ArrayIterator - it defines exactly what the class is while Array doesn't convey very well by itself. You have to look at the full name in order to understand the process. This also becomes ambiguous when you're reading the code in PHP. What does $a = new Array($some_array); do? You have to go back to the uses declaration at the top to figure it out. This is true for most of the names I'm seeing here. Range, Info, Object, Logic, etc. What kind of Range, Info about what, a plain Object, an ArrayObject, or something else? You end up with more verbose names by going to a PEAR1 style of naming convention because you have to use the entire name with the namespace in order to convey what the code is supposed to be doing. I would stick with names more closely related to the original names and add spl:: (see next comment for lowerspace) to signify that they're part of SPL. So instead of RecursiveArrayIterator, you have spl::RecursiveArrayIterator; SplFileInfo becomes spl::FileInfo, etc. * I would change everything except the final class name in the full name to be lowercase. Using your existing examples: Spl::List::DoublyLinked would be spl::list::DoublyLinked, or better yet spl::DoublyLinkedList, etc. This helps denote what is a class and what is part of the namespace name. In the original examples, its ambiguous as to what can be instantiated. Are Spl and Spl::List classes that can be instantiated? Moving to the lower space convention makes it easy to denote what is a class and what is just part of the namespace. This follows the path created by several other languages. Thanks for bringing this up. Hopefully we can start using namespaces in at least some parts of PHP to help promote their best uses throughout the language. -T -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: teckie
PHP 6+ Development, Docs, and builds -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Magic method visibility in PHP 5.3+
Daniel Convissor escribió: Because that's what the manual says it should do. Right, however I disagree with the fact it is a warning, it should be a fatal error IMHO. -- A computer is like an Old Testament god, with a lot of rules and no mercy. Cristian Rodríguez R. Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research Development http://www.opensuse.org/ signature.asc Description: OpenPGP digital signature
