Re: [PATCH] [RFC] Closures and lambda functions in PHP
| From: | Marcus Boerger | Date: | Fri, 20 Jun 2008 08:36:26 +0000 |
| Subject: | Re: [PATCH] [RFC] Closures and lambda functions in PHP | ||
| References: | 1 2 3 4 5 6 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-38448@lists.php.net to get a copy of this message | ||
Hello Andi,
Thursday, June 19, 2008, 8:44:07 AM, you wrote:
> See below:
>> -----Original Message-----
>> From: Christian Seiler [mailto:chris_se@gmx.net]
>> 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.
I though we are speaking of PHP here? And all I remeber is that PHP has
reference counting. So it doesn't matter if we do reference or value
binding. We simply have to increase the internal reference counter - done.
>
>> >> - 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
Best regards,
Marcus