Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61485
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CABBJUpcwMi-A84+a99-h1wZ1sbQ4R5DAZ_uBPh+fQd4+AmD8FA@mail.gmail.com>
References: <CABBJUpfVf2-LKenbfxWrO8nB3cd-K-wyf34wURywXgw379vo6Q@mail.gmail.com>
	<CAPwsocGHoFV48MmnqhDWK9LeG-RNMcYVJ4qCfBpdm6keN_8RuA@mail.gmail.com>
	<CABBJUpc9_kdLiRYUqCDnyRpmRQo6HEVZehJ+yj7uXjt5SdzF3Q@mail.gmail.com>
	<CABBJUpcwMi-A84+a99-h1wZ1sbQ4R5DAZ_uBPh+fQd4+AmD8FA@mail.gmail.com>
Date: Thu, 19 Jul 2012 10:13:15 -0400
Message-ID: <CAAyV7nFQV08NGTXhmZTEs5n+GLwipEuRkuL2AWHk2dEosovGtg@mail.gmail.com>
To: Laruence <laruence@php.net>
Cc: Nikita Popov <nikic@php.net>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=20cf30334fad6b96ac04c52f6183
Subject: Re: [PHP-DEV] Call for voting: [RFC] Allow use T_AS in closure use statement
From: ircmaxell@gmail.com (Anthony Ferrara)

--20cf30334fad6b96ac04c52f6183
Content-Type: text/plain; charset=ISO-8859-1

Laruence,

On Wed, Jul 18, 2012 at 9:53 PM, Laruence <laruence@php.net> wrote:

> 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

--20cf30334fad6b96ac04c52f6183--