On Thu, 03 Jul 2008 11:06:48 +0200, Christian Seiler <[EMAIL PROTECTED]> wrote:
> Hi,
> 
>> 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?
> 
> Yes, of course. :)

Just making sure. :-)

>> 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?
> 
> It's up to the programmer for now, static => no $this, no static =>
> $this.

Hm.  I defer to those who understand the guts of the engine on whether that's a 
good call or not.  If left as is then the user docs should be very clear about 
the potential for memory issues there, since most lambas I suspect will not 
need a $this, even if they happen to be defined within a method.

>> 3) Can __invoke() accept parameters,
> 
> Yes.

Neato.  That should also be included in the user-side docs.

>> 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?
> 
> Probably. But if we start picking on every detail of the patch until it
> is absolutely perfect, it will never get committed, not even to HEAD. So
> I propose that it should be committed to HEAD (as long as there are no
> major objections) and then worry about tiny details afterwards.

As a rank-and-file PHP developer, I have no major objections remaining that 
aren't bikeshed questions. :-)  (And I certainly understand the desire to get 
the base committed and polish/extend in follow-up patches, as I am doing so 
myself on another project.)

>> 5) There's a couple spelling and grammar errors. :-)
> 
> Feel free to correct them if you have access to the wiki.

I do not believe I do.

--Larry Garfield


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to