Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99588
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mindplay.dk from 209.85.192.170 cause and error)
MIME-Version: 1.0
In-Reply-To: <DC4F8FEC-7EAA-4D14-BD57-C48DC0A7D392@gmail.com>
References: <CAFMT4Npoo_ZrRk-kk4C6KHYEtV93pU7Wmh0FhaPi6Z-9qkObaQ@mail.gmail.com>
 <CAESVnVpQtLXhKnUn2EE4s7rZn11r5Kpj2zOSOKRCWFaxaeOrjg@mail.gmail.com>
 <b1105f90-91e9-e61a-b96b-5078c337ab5c@telia.com> <b47c4379-109c-c289-1077-b42ea40fe19f@telia.com>
 <ca6f11d0-5da3-757c-7acd-4acd79a876f1@fleshgrinder.com> <5fe1eefe-1c4f-4c31-c975-ab6c768c977c@telia.com>
 <E56D1F4A-6DC7-47DA-BAD6-1722E017B048@me.com> <CADqTB_jDmFZZc3ah=J8F99P77qnuWVgXS5UwXgrbartCp5B+UQ@mail.gmail.com>
 <3C763609-54FC-480B-AE95-94A1873226E0@me.com> <CADqTB_hU+38TOHdaukhGBS-2NPq-PNSci1h078TPOGbE7WcmWg@mail.gmail.com>
 <9A3447BF-F982-4C5A-B55B-466036AF2E53@me.com> <CAFMT4NrdCRJxGyeGqLbAoaV896FN6VpDjY-68trXoaRgZe4VyQ@mail.gmail.com>
 <CADqTB_hT-Nd5wX129GgeQxL8RNJ85maSPOPHUt-2NK-ef3yF-g@mail.gmail.com>
 <CADqTB_hB1ifmXu4VO6Z4A3gN=2AF_PU4C8yCYXz8QN6zZ_k=6w@mail.gmail.com>
 <2d89daaa-056f-3dcb-a5f2-b790affe203a@garfieldtech.com> <CADqTB_gN+bdU9HBbyjpJJCK7FxO_rQi9hmEuhANGEkc52mpHtw@mail.gmail.com>
 <DC4F8FEC-7EAA-4D14-BD57-C48DC0A7D392@gmail.com>
Date: Wed, 21 Jun 2017 16:04:46 +0200
Message-ID: <CADqTB_jXUtjVMexZOScHN96sQYgLKdws6_rGCWV8MDriSe4hCQ@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="94eb2c187e24d1ab22055278d918"
Subject: Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions
From: rasmus@mindplay.dk (Rasmus Schultz)

--94eb2c187e24d1ab22055278d918
Content-Type: text/plain; charset="UTF-8"

> For me (and I am not alone), this feature is NOT a new syntax for closures

Regardless of why you want it, that's exactly what it is though - another
way to declare a closure.

Even if it has different semantics, the resulting object is still an
instance of Closure, right?

It should pass type-checks, it should support reflection, and so on -
otherwise, that's even more inconsistency, for no practical reason, and it
will lead to an endless list of problems which people will solve with even
more ugly work-arounds, such as omitting type-hints, etc.

> If what you are looking for is a replacement syntax for existing
closures, you will have a completely different set of priorities

I am not looking for a replacement syntax, but rather a replacement feature.

I think the priorities and requirements remain the same, but for
consistency, and to keep this feature generally useful, this feature should
have parity with current Closures in terms of capabilities - otherwise it
will get in the way rather than help.

Once people see the nicer, shorter syntax, and start to enjoy the more
natural scoping rules, it's going to be very frustrating to have to
back-port to the old function-syntax and add use-clauses etc every time the
code changes and a single expression doesn't cut it.

A single-expression constraint on this feature would be a strange,
arbitrary, annoying, unnecessary limitation.

We didn't get it right the first time. Let's get it right this time, not
just adding another feature as a work-around to certain specific cases.

We have closures - no matter how you view it or describe it, regardless of
why you want this feature, this is another way to create closures, and it
needs to have parity with the existing feature.

Unless you're saying these are an entirely new type of object that isn't an
instance of Closure, in which case I'd say this whole feature is guaranteed
to do considerably more harm than good?


On Tue, Jun 20, 2017 at 7:52 PM, Rowan Collins <rowan.collins@gmail.com>
wrote:

> On 19 June 2017 21:22:53 BST, Rasmus Schultz <rasmus@mindplay.dk> wrote:
> >So what's on the table is a syntax-improved but feature-crippled
> >variant of
> >closures, not an all-round replacement?
>
> I haven't the time right now to dig out my summary from the mail archives,
> but this is one of the fundamental disagreements / misunderstandings that
> made discussion difficult the first time: different people want very
> different things from this feature, leading to conflicting views on whether
> certain things are advantages or disadvantages.
>
> For me (and I am not alone), this feature is NOT a new syntax for
> closures. It is a new TYPE of closure, with new semantics - automatically
> capturing variables - for a specific use case.
>
> Personally, I am strongly opposed to any multi-line version of it, because
> I don't want the fundamental scoping rules of the language changed except
> for the specific case of simple lambda expressions.
>
> If what you are looking for is a replacement syntax for existing closures,
> you will have a completely different set of priorities. That doesn't make
> either of us wrong, but it does mean we're going to find it very hard to
> agree on a syntax and feature set.
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--94eb2c187e24d1ab22055278d918--