Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:38721
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.162 as permitted sender)
Message-ID: <486C7F5F.3080007@zend.com>
Date: Thu, 03 Jul 2008 11:27:27 +0400
User-Agent: Thunderbird 2.0.0.14 (X11/20080501)
MIME-Version: 1.0
To: Lukas Kahwe Smith <mls@pooteeweet.org>
CC: Christian Seiler <chris_se@gmx.net>, 
 php-dev List <internals@lists.php.net>
References: <486B6960.4030705@gmx.net> <3F379336-B4DC-4495-AD76-3D52ED703E0E@pooteeweet.org>
In-Reply-To: <3F379336-B4DC-4495-AD76-3D52ED703E0E@pooteeweet.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Closures: updated proposal and patch
From: dmitry@zend.com (Dmitry Stogov)

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
> 
> 
> 
>