Re: [RFC] Closures: updated proposal and patch

From: Date: Thu, 03 Jul 2008 18:33:19 +0000
Subject: Re: [RFC] Closures: updated proposal and patch
References: 1 2 3 4 5  Groups: php.internals 
Request: Send a blank email to internals+get-38740@lists.php.net to get a copy of this message
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:dmitry@zend.com] 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 mls@pooteeweet.org
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php


« previous php.internals (#38740) next »