Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:38666
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: <4866004B.3070805@zend.com>
Date: Sat, 28 Jun 2008 13:11:39 +0400
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Alexander Wagner <waqner@gmx.net>
CC: internals@lists.php.net, Andi Gutmans <andi@zend.com>, 
 Christian Seiler <chris_se@gmx.net>,
 Stas Malyshev <stas@zend.com>
References: <4856A547.3080801@gmx.net> <48651D20.6050301@zend.com> <698DE66518E7CA45812BD18E807866CE01BD0FA5@us-ex1.zend.net> <200806272130.50007.waqner@gmx.net>
In-Reply-To: <200806272130.50007.waqner@gmx.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [PATCH] [RFC] Closures and lambda functions in PHP
From: dmitry@zend.com (Dmitry Stogov)

Thanks for "static function ()" idea, it's much better and consistent 
than "function () use ($this)". I think we should go this way.

Do you see any other issues with the patch?

Thanks. Dmitry.


Alexander Wagner wrote:
> On Friday 27 June 2008, Andi Gutmans wrote:
>> I am not sure I like the idea of explicit $this.
>> [..] If we ever discover this is a huge issue
> 
> Implicit unoptimized $this is never going to be a "huge issue", because it is 
> not badly broken, only sublty.
> My crystal ball tells me that the following is going to happen:
> - Many people who use closures will expierience a slight increase in memory 
> consumption due to closures. They won't notice though, unless they run on a 
> memory_limit with little margin for error.
> - Developers with objects that use a lot of memory (e.g. because they contain 
> large strings or hold references to many other objects) will expierience a 
> significant increase in memory consumption (constant or linear) that may be 
> enough to cause noticable performance degradation and pop quite a few memory 
> limits. This is going to be relatively rare, but it will happen regularly. 
> PHP has a lot of users using shared hosting services.
> - A very small number of developers will manage to implement an algorithm 
> whose space complexity is changed from O(1) to O(n) or worse, which can 
> easily cause a catastrophic increase in memory consumtion, even when PHP is 
> operating without memory limit.
> 
> Also, most of the developers to whom this happens will either not notice at 
> all or be unable to give accurate feedback, so if this does become a 
> significant problem, you may never find out.
> 
>> we can always add support for something like "static function() {}" 
> 
> That kind of implies that the lambda-function is part of the class because it 
> was created inside the class. I don't like this notion. Membership in the 
> class should be reserved for actual members.
> 
> You could start with explicit $this, which is inconvenient but safe.
> If enough developers complain about the inconvenience, you have a lot of time 
> to think about how to implement an optimized implicit $this. I don't see any 
> BC-problems here.
> 
> "Start safe, optimize later" seems sounder than "Start sublty broken, fix 
> later".
> 
> Gesundheit
>   Wag
>