Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99364
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.25 cause and error)
To: internals@lists.php.net
References: <CAFMT4Npoo_ZrRk-kk4C6KHYEtV93pU7Wmh0FhaPi6Z-9qkObaQ@mail.gmail.com>
 <DM3PR18MB07641E547AD2FA1DFA5BEF65DEF60@DM3PR18MB0764.namprd18.prod.outlook.com>
 <6357d97c-3f2e-4cf8-cb1f-cb7f7ccccf7c@telia.com>
 <CADqTB_hNob7ZiGX66gJEpCymrZJqqsZ1uAGnYg6v6sbrwx1-KQ@mail.gmail.com>
Message-ID: <7eaef49b-bf60-9aa1-e812-8430164e3178@garfieldtech.com>
Date: Mon, 5 Jun 2017 11:17:02 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <CADqTB_hNob7ZiGX66gJEpCymrZJqqsZ1uAGnYg6v6sbrwx1-KQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Subject: Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions
From: larry@garfieldtech.com (Larry Garfield)

On 06/05/2017 09:19 AM, Rasmus Schultz wrote:
> Of the proposed options, I'd prefer the double fat-arrow ==>
>
> However, I remain of the opinion that all of those syntaxes are
> work-arounds to ambiguity concerns for cases that likely don't actually
> occur in real-world codebases.
>
> I don't understand the motivation to design or optimize based on some
> theoretical concerns - I'd strongly prefer we do the obvious thing, which,
> as I see it, would be to do what most languages do, e.g. the familiar fat
> arrow => syntax.
>
> If we're going to provide a closure feature that works more like what you'd
> typically find in other languages, we should try to also make it look like
> it does in most other languages.
>
> It was said of the generics syntax that I proposed that it would have
> ambiguity issues, that it would be impossible (or very difficult) to
> implement, but someone actually went an implemented it. I'm generally a bit
> skeptical of people who cry "impossible" before giving it their best effort.
>
> Inventing unfamiliar syntax for familiar features should be a painful last
> resort, if there is no other choice.
>
> Just my opinion.
>
> I'd love to have this feature, but I'd prefer we don't introduce anymore
> "muck" if it's at all avoidable.
>
>
> On Mon, Jun 5, 2017 at 3:10 PM, Björn Larsson <bjorn.x.larsson@telia.com>
> wrote:
>
>> Den 2017-06-01 kl. 18:58, skrev Theodore Brown:
>>
>> On Tuesday, May 30, 2017 at 12:58 PM, Levi Morrison wrote:
>>> Based on the discussion there are a few different syntax choices
>>>> people liked. Overall it's a feature that people seem to want but
>>>> everyone seems to prefer a different syntax choice.
>>>>
>>>> 1. fn(params) => expr
>>>> 2. function(params) => expr
>>>> 3. (params) ==> expr
>>>> 4. (params) => expr
>>>> 5.
>>>> [](params) => expr // binds no values
>>>> [=](params) => expr // binds by value
>>>> [&](params) => expr // binds by reference
>>>>

3 > 4 > 1.

2 is not even worth considering and I'd almost prefer not having arrow 
functions if their syntax is going to be that self-defeating.

I also see no reason to include both by-value and by-reference binding  
Arrow functions are for trivially simple cases where the extra ceremony 
of an anonymous function is a waste.  If you need to do something 
non-trivial, use a full-on anonymous function as we already support.

I want to reiterate that, from a user-POV, arrow functions are barely 
functions.  It's a case for applying an expression to a set. In most 
cases I don't "think about it" as a function in the first place.

$y = 2;
array_map($arr, ($x)=> $x*$y);

While I know that implementation-wise $x * 2 gets wrapped into a 
function, that's not really how I'm mentally thinking about it.  I'm 
thinking of it more like a single line in a foreach.  In my head, it's 
an expression, not a function.  If I needed to be "thinking about it 
like a function", I'd use a more function-esque syntax.

The extra complication of multiple binding styles to think about are 
just that: extra complication.  If I care, then I should be using an 
anonymous function whose use() syntax already lets me control that case.

I wonder if "Arrow functions" is even a misleading name for the feature, 
in terms of how it should be used.

--Larry Garfield