Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87963
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.52 as permitted sender)
Content-Type: text/plain; charset=koi8-r; format=flowed; delsp=yes
To: internals@lists.php.net
References: <BLU436-SMTP13020F8CE8795C628BDC665E26B0@phx.gbl>
 <55E4C19F.4060704@gmail.com>
Date: Tue, 01 Sep 2015 00:32:07 +0300
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Message-ID: <op.x384rtfxc9evq2@nikita-pc>
In-Reply-To: <55E4C19F.4060704@gmail.com>
User-Agent: Opera Mail/12.17 (Win32)
Subject: Re: [PHP-DEV] [RFC] [Discussion] Short Closures
From: inefedor@gmail.com ("Nikita Nefedov")

On Tue, 01 Sep 2015 00:05:35 +0300, Stanislav Malyshev  
<smalyshev@gmail.com> wrote:

> Hi!
>
>> I had this RFC in draft since some time, but delayed it due to all
>> the ongoing PHP 7 discussions. Also we have no master branch to merge
>> features in until 5.4 EOL. Thus I'm reviving this now.
>>
>> Time for the first RFC targeting PHP 7.1 (assuming PHP 8 isn't going
>> to be the next version ;-)):
>>
>> The short Closures RFC: https://wiki.php.net/rfc/short_closures
>
> I personally don't see much advantage in making PHP code less readable
> and harder to parse. Also, "automatically use () all of the (compiled)
> variables" does not look like a good idea - first, users have no idea
> what compiled variables are, so the result would be unpredictable for
> them, second, if there are a lot of variables in the scope (like global
> scope) it would have huge performance costs for no gain.
> Also, this syntax does not allow "use by-ref" which the existing syntax
> does allow.
>
> I think we already have syntax for anonymous functions and it works. The
> only addition in this RFC is automatically gobbling up all local
> variables, which in vast majority of use cases is not what the function
> needs.

Hi Stas,

Capture of all variables from the current scope is not the only addition  
in this RFC. The main addition (which is extended by that btw) is making  
the syntax shorter. Which, in turn, makes it easier to write and read  
closures. I've had a huge lot of cases where I would benefit from it,  
things like this:

   $collection = array_filter(array_map(function (Type $el) { return  
$el->getStuff(); }, $collection));

It would be much easier to read and write with the short syntax:

   $collection = array_filter(array_map((Type $el) ~> $el->getStuff(),  
$collection));

Just because, I'll say it, the less symbols you have to read the faster  
you'll read it. To some extent, of course, a counter-example being Perl  
language. But I don't think that we are even close to it.

Your point about capturing too much if you have too much in the global  
scope is legit but in this case I'd say two things: you can still use long  
closure syntax, and second you have a problem with global scope not short  
closures.

You see the main use case for anon. functions is when you need a  
*lightweight* callback for something. If it were a fat function I'd  
probably make it named and write tests for it. But when it's a small  
function, often consisting from only one expression it kinda bothers me  
when the body of this function takes less keystrokes than 'function' and  
'return' keywords...