Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:38740
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 204.11.219.139 cause and error)
Message-ID: <486D1B6F.20803@lerdorf.com>
Date: Thu, 03 Jul 2008 11:33:19 -0700
User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604)
MIME-Version: 1.0
To: Dmitry Stogov <dmitry@zend.com>
CC: Andi Gutmans <andi@zend.com>, Lukas Kahwe Smith <mls@pooteeweet.org>,
        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> <486C7F5F.3080007@zend.com> <698DE66518E7CA45812BD18E807866CE01C3A902@us-ex1.zend.net> <486D1AD3.3080708@zend.com>
In-Reply-To: <486D1AD3.3080708@zend.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Closures: updated proposal and patch
From: rasmus@lerdorf.com (Rasmus Lerdorf)

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
>