Re: [RFC] Closures: updated proposal and patch

On Thu, 03 Jul 2008 11:06:48 +0200, Christian Seiler <chris_se@gmx.net> 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