Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105960
MIME-Version: 1.0
References: <CAOv67gumG=mdj1Nr=uXtRTSdxGOMEu8=TZizdpgf5AsoaRVGDg@mail.gmail.com>
 <CADyq6sJX+cAfUrMiGA3_9drMS=+fCVvySNroy0BfNF1VcRxwFg@mail.gmail.com>
 <CAOv67gtUm5_6dbh6G25hC7DeNSCsL7VrGqX8JVp3Uu+a=JN-GQ@mail.gmail.com> <CAJW__o3Qf5_ePp-o7abJ72UPKVAUSVhtusKxyJgFG=emx_q16g@mail.gmail.com>
In-Reply-To: <CAJW__o3Qf5_ePp-o7abJ72UPKVAUSVhtusKxyJgFG=emx_q16g@mail.gmail.com>
Date: Mon, 17 Jun 2019 16:37:30 +0100
Message-ID: <CALKiJKp7jQHq=S6SSjn_TJi8JutsGgwwbvXJ-wsn8jeDMj-Ebw@mail.gmail.com>
To: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000d1612c058b86c6e5"
Subject: Re: [PHP-DEV][RFC] Alternative "use" syntax for Closures
From: rowan.collins@gmail.com (Rowan Collins)

--000000000000d1612c058b86c6e5
Content-Type: text/plain; charset="UTF-8"

On Sat, 15 Jun 2019 at 23:22, Kalle Sommer Nielsen <kalle@php.net> wrote:

> The proposed syntax was also that of the proposed syntax when closures
> arrived in 5.3 (and back then it was using the then keyword
> 'lexical'), anyway. I believe the current syntax was chosen due to
> scopes, as values are bound specifically when the closure is created
> and not when the closure is executed.
>


Hi Kalle,

Thanks for the background info, I've often wondered why the syntax isn't
more similar to "global" and "static" declarations. It hadn't occurred to
me before that the function signature can be processed without inspecting
the function body.

While I think the proposed syntax has its upsides, I agree with others that
adding it as an alternative at this stage doesn't add very much. People who
don't like explicit imports still won't like it, and people who are used to
the existing syntax will write style guides prohibiting the new.

When I suggested on SO chat that a long list of imports was a similarly bad
sign as a long list of parameters, I was scoffed at, so I would be
interested to see examples where large numbers of imports are justified.

Assuming there are such use cases, it seems like automatic capture will be
a better solution. I'm not personally keen on extending the arrow syntax
with a full body - "fn()=>{}" is barely shorter than "function(){}", and I
think "arrow functions are for short expressions" is a useful distinction
and constraint.

If we really need automatic capture, I'd prefer for it to be opted into in
the normal syntax, e.g. "function() use(*) { ... }". We could even have
"use(&*)" for "automatic capture by reference", if we wanted to go that far.

Regards,
-- 
Rowan Collins
[IMSoP]

--000000000000d1612c058b86c6e5--