See below: > -----Original Message----- > From: Christian Seiler [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 18, 2008 1:14 PM > To: php-dev List > Subject: Re: [PHP-DEV] [PATCH] [RFC] Closures and lambda functions in PHP > > Frankly, I don't really see a problem with using references. It fits > into what's already there in PHP and it assures that closures have the > necessary properties to make them useful.
I think you are right that there isn't really a good alternative as the "parent" scope does not necessarily exist anymore. Your solution is likely the best. > >> - Please check eval(). I assume it will bind to global scope but > >> let's just make sure what happens esp. when it's called from within > >> a method... > > Hmm, closures inside eval() will bind variables to the scope in which > eval() was called. But closures defined inside eval will NOT be class > methods, even if eval() is called within a class. > > But I do find that behaviour consistent with what PHP currently does > with normal functions and variables: If eval()'d or include()'d inside a > function, variables will the "global scope" of eval() or the included > file will actually be the local function scope whereas defined functions > inside will automatically become global functions. > > Of course, this behaviour should be documented but I don't see a reason > to try and change it. I agree. It behaves as I would expect I just wanted to make sure you verify that because I didn't have the opportunity to do so. You'd actually have to work very hard for it not to behave in that way :) Let's just make sure we have unit tests for both cases just so we have a good regression on this one. > >> - In PHP 5, object storage is resources done right. I don't think > >> we should be using the resource infrastructure for this > >> implementation and would prefer to use the object one. It's better. > >> I suggest to take a look at it. > > Hmm, seems like a good idea. If nobody objects in the next few days, > I'll rewrite my patch to use objects instead of resources. What class > name do you suggest? Great. I think Closure is probably a good name. [Btw, if we want to get fancy we could even have a __toString() method on those which would print out information about the Closure. But this is not a must, just something which eventually could be nice for debugging purposes...] > PS: Somebody made me aware of a segfault in my code when destroying the > closure variable while still inside the closure. I'll fix that. :) Thanks, Andi
