Call for voting: [RFC] Allow use T_AS in closure use statement View as Markdown

Hi:
I saw you two vote against for this RFC.

could you explain why?  then maybe I can improve it.

thanks

I can't speak for them, but it might have something to do with a lack of
information. I don't recall seeing the discussion thread on this, either.
Though I could've just missed it. More specifics I think would be helpful.

--Kris

Laruence,

Hi:
I saw you two vote against for this RFC.

could you explain why?  then maybe I can improve it.

thanks

The reason that I voted against it is simple. It's sugar to make it harder
to understand what the code is doing, and blur the line of what the closure
is doing.

Closures are supposed to "wrap" a parent scope (in other words, "close in
on it"). The closure isn't a strictly new scope, but an extension on the
existing one. PHP muddied this concept with the USE declaration (rather
than importing the parent scope in its entirety, as almost every other
language does). But this change would muddy it even further.

My argument would be that if you really need to rename variables for
clarity, you don't belong putting it in a closure in the first place (as
it's way too much logic that needs to be split out into a separate function
entirely).

Additionally, it will further confuse the subject because:

$f = function() use ($this as $obj) {
$obj->protectedMethod(); // fatal error, as it's not in the same scope
}

That will fail for non-obvious reasons. At least currently there's an extra
level of indirection required to pass $this, so it's a little bit clearer
that you're not passing $this to the object, but a copy of it.

Additionally, we need to think about the coupling between the closure's
scope and the parent scope. There is -by design- very tight coupling
between them. And not even from a language level. The closure is defined
inside of another function, at a specific point in execution to use
certain aspects of the parent scope. That means that it's highly coupled to
the parent function. Actually, it's has cohesion in almost all forms:
Logical, Temporal, Procedural, Communicational, Sequential and Functional.
The only form of cohesion that it doesn't directly and automatically have
is Coincidental... Therefore, their scopes are always going to be tightly
coupled (which is what we want with a closure).

If you really need to rename variables into the closure, create a factory
for the closure:

$closureFactory = function ($a, $b, $c) {
return function() use ($a, $b, $c) {
};
};

Yes, it's an extra level of indirection, but that indirection is explicit
rather than implied....

So, I guess in summary, I would say that I voted against it because it
further blurs the line between what a closure is and what PHP implements
(which is already fairly blurry).

That's my $0.02 at least...

Anthony