Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:38717
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 76.96.30.56 cause and error)
To: internals@lists.php.net
Date: Wed, 2 Jul 2008 20:13:13 -0500
User-Agent: KMail/1.9.9
References: <486B6960.4030705@gmx.net>
In-Reply-To: <486B6960.4030705@gmx.net>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-ID: <200807022013.14288.larry@garfieldtech.com>
Subject: Re: [PHP-DEV] [RFC] Closures: updated proposal and patch
From: larry@garfieldtech.com (Larry Garfield)

On Wednesday 02 July 2008 6:41:20 am Christian Seiler wrote:
> Hi,
>
> After some discussion with Dmitry, he and I have continued to improve
> the current closure patch. You can find the current proposal with
> patches for 5_3 and HEAD here:
>
> http://wiki.php.net/rfc/closures
>
> (Please read it again, I've changed quite a lot.)
>
> Basically, it's the syntax with use ($lexical) in the function
> declaration, optional references, optional static keyword for functions
> that don't need $this and support for __invoke. I know that there was
> some disagreement on the syntax (including by me) but I think this is
> the best compromise we can achieve while still staying consistent with
> PHPs current semantics and not breaking BC at all.
>
> I've spoken to Dmitry and he said the patch will be committed to HEAD
> soon. Since both Dmitry and I still want to have it in 5_3 too, we'd
> want to ask for opinions on this again - especially since after quite a
> lot of thorough review and discussion on this list basically all the
> side-effects have been addressed and there are now quite a few tests
> that ensure the correct behaviour of closures. Also, the patch is now
> built in a way that the main functionality remains inside
> zend_closures.c, so any possible not yet encountered bug can be fixed
> without breaking binary compability.
>
> Regards,
> Christian

Questions:

1) The RFC page says that closures pass by value by default.  Although it is 
not stated, am I correct in saying that due to the way resources and objects 
(and presumably therefore lambdas) are handled they will still have the 
effect of passing by reference anyway, just as with a function parameter?

2) It is unclear from the RFC if static class closures (I am not fond of that 
syntax, I grant) are the only ones that won't import $this.  Is the suggested 
detection optimization not included, and therefore it's up to the programmer 
to avoid dangling references that keep stray classes around?  Or is the 
engine going to be "smart" about that, static keyword or no?

3) Can __invoke() accept parameters, or is it an empty param list only?  (I 
suppose I can see arguments either way here; I just don't know what the 
current implementation does.)

4) The ability to reflect and then call a function or method as a closure 
sounds highly nifty.  However, I am unclear on why it is necessary to pass in 
the $this to use.  In that case, wouldn't it make more sense to use 
ReflectionObject() in the first place so that the $this is implicitly known?

$object = new Example;
$r = new ReflectionObject($object);
$method = $r->getMethod('printer');
$closure = $method->getClosure ();
$closure();

5) There's a couple spelling and grammar errors. :-)

-- 
Larry Garfield
larry@garfieldtech.com