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
