> Yes, the original used "$this->getFooBar()" -- but it could have been
> "$someOtherObject->getFooBar()"
Yep, you and Anthony are right, my comment was stupid...
Then I have an other objection :)
I'm not comfortable with mixing declarative lines with expressions:
function (..) use (..) is always purely declarative, whatever the (..)
but
function (..) use ((expression) as $foo) isn't any more.
I would feel the same e.g. with a syntax like:
function ($a = $foo->bar()) {} (a closure with default argument calculated
once but give as expression.)
If you like "use ((expr) as $foo)", do you like the above?
This is an open question, a yes would be coherent,
but otherwise, why allow one and not the other?
> > > Also, remember that the closure is in fact another function, a
> function
> > > that performs its own actions independent of the parent.
> >
>
> Actions may be independent, but as a closure is declared inside its
> parent,
> > both codes have very strong relationship. For the reader, overriding this
> > relationship with new closure-local var names can weaken its
> understanding
> > of the code don't you think?
>
> The closure is a function itself; readability within it is just as
> important as readability of the parent. I'd personally rather not have a
> lot of boilerplate code marshalling variables to start off my closure --
> I'd rather they were simply declared and ready for use.
>
The closure is yours, but the parent is also yours, so if you think $l is
better than $long, then why not for the parent also?
Naming (and understanding) things is hard enough to not give two names to
the same code-local thing...
But that's only me sharing my feeling :)
Nicolas
