Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:38338 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 2283 invoked from network); 18 Jun 2008 01:59:47 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 18 Jun 2008 01:59:47 -0000 Authentication-Results: pb1.pair.com smtp.mail=larry@garfieldtech.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=larry@garfieldtech.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 76.96.30.32 cause and error) X-PHP-List-Original-Sender: larry@garfieldtech.com X-Host-Fingerprint: 76.96.30.32 qmta03.emeryville.ca.mail.comcast.net Received: from [76.96.30.32] ([76.96.30.32:36484] helo=QMTA03.emeryville.ca.mail.comcast.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 0A/45-03584-21C68584 for ; Tue, 17 Jun 2008 21:59:46 -0400 Received: from OMTA05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id f0zC1Z00S0vp7WLA31GE00; Wed, 18 Jun 2008 01:59:43 +0000 Received: from earth.ufp ([24.13.255.226]) by OMTA05.emeryville.ca.mail.comcast.net with comcast id fDzZ1Z00U4trKQ88RDzaaW; Wed, 18 Jun 2008 01:59:35 +0000 X-Authority-Analysis: v=1.0 c=1 a=IWnH0euKuzgA:10 a=K8k5FXa3V3kA:10 a=QNfgFXVBJYwGSyt0UxgA:9 a=CuQL0BP17F0k4BOhtrmVwAOVRFAA:4 a=FHBbIDN7CdwA:10 a=LY0hPdMaydYA:10 Received: from localhost (localhost [127.0.0.1]) by earth.ufp (Postfix) with ESMTP id 5749AD86E6 for ; Tue, 17 Jun 2008 20:59:33 -0500 (CDT) Received: from earth.ufp ([127.0.0.1]) by localhost (earth.ufp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZzrl1+yDfrD for ; Tue, 17 Jun 2008 20:59:32 -0500 (CDT) Received: from vulcan (unknown [192.168.42.1]) by earth.ufp (Postfix) with ESMTP id 71ED5D86E4 for ; Tue, 17 Jun 2008 20:59:31 -0500 (CDT) To: internals@lists.php.net Date: Tue, 17 Jun 2008 20:59:25 -0500 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <4856A547.3080801@gmx.net> <200806162257.24141.larry@garfieldtech.com> <48576A39.9040208@gmx.net> In-Reply-To: <48576A39.9040208@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <200806172059.25933.larry@garfieldtech.com> Subject: Re: [PHP-DEV] [PATCH] [RFC] Closures and lambda functions in PHP From: larry@garfieldtech.com (Larry Garfield) On Tuesday 17 June 2008, Christian Seiler wrote: > Hi, > > > - I am a little confused about the OOP interaction. How does a function > > become a public method of the class? > > To clarify: the "public method" ist just the internal representation of > the lambda function and has *nothing* to do with the semantics of > calling the lambda itself. The "method" only means that the lambda > function defined inside another method can access the class members and > "public" only means that the lambda function can still be called from > outside the class. If one knew how to access it, which it seems is not possible/feasible for user-space code. > > class Example { > > private $a = 2; > > > > function myMethod($b) { > > $lambda = function() { > > lexical $b; > > return $this->a * $b; // This part I get > > }; > > return $lambda; > > } > > } > > > > $e = new Example(); > > $lambda = $e->myMethod(); > > $e->$lambda(5); > > No, that's not what my patch does. My patch does: > > class Example { > private $a = 2; > > public function myMethod ($b) { > return function () { > lexical $b; > return $this->a * $b; > }; > } > } > > $e = new Example (); > $lambda = $e->myMethod (4); > var_dump ($lambda ()); // int(8) > $lambda2 = $e->myMethod (6); > var_dump ($lambda2 ()); // int(12) > > So esentially, it does not matter whether you define a lambda function > inside a method or a function (or in global scope, for that matter), you > always use it the same way. The in-class-method lambda function only has > the additional advantage of being able to access the private and > protected class members since *internally* it is treated like a public > class method. I see. It would be great if you could update the RFC with this information so that it's clearer. > If you want to add methods dynamically to classes, why not use the > runkit extension? I really don't see a point in making lambda functions > and closures something they are not. I was asking if they could be used for that, not to make them into a different animal. As for using runkit, do I really need to answer that? :-) Two other questions that just occurred to me: 1) What is the interaction with namespaces, if any? Are lambdas as implemented here ignorant of namespace, or do they take the namespace where they are lexically defined? 2) What happens with the following code? class Foo { private $a; } $f = new Foo(); $b = 5; $f->myfunc = function($c) { lexical $b; print $a; // This generates an error, no? print $b; // This prints 5, right? print $c; // Should print whatever $c is. } $f->myfunc(3); Or is the above a parse error entirely? -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson