RE: [PHP-DEV] [PATCH] [RFC] Closures and lambda functions in PHP

See below: > -----Original Message----- > From: Alexander Wagner [mailto:waqner@gmx.net] > Sent: Friday, June 27, 2008 12:31 PM > To: internals@lists.php.net > Cc: Andi Gutmans; Dmitry Stogov; Christian Seiler; Stas Malyshev > Subject: Re: [PHP-DEV] [PATCH] [RFC] Closures and lambda functions in PHP > > 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. Uhm, but we are already discussing closures which belong to the class. In fact, what I suggest is not different from what the current proposal is. I actually think this is *much* cleaner and more straightforward than any constructs which rely on some explicit $this to be passed. > 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". I don't really consider it broken and I don't think that this additional syntax is what I'd call start safe. I already made a suggestion for how to fix this down the road. And if there's a preference to do it today I don't mind having the "static function" syntax today. I think it's extremely consistent with what PHP already does. Cheers, Andi