Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99627
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mindplay.dk from 74.125.83.46 cause and error)
MIME-Version: 1.0
In-Reply-To: <76f05ddb-fe72-fa90-e3a0-8e5233952aa1@gmail.com>
References: <CAFMT4Npoo_ZrRk-kk4C6KHYEtV93pU7Wmh0FhaPi6Z-9qkObaQ@mail.gmail.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> <CADqTB_jXUtjVMexZOScHN96sQYgLKdws6_rGCWV8MDriSe4hCQ@mail.gmail.com>
 <76f05ddb-fe72-fa90-e3a0-8e5233952aa1@gmail.com>
Date: Fri, 23 Jun 2017 20:43:19 +0200
Message-ID: <CADqTB_hmyp3NhS=Se-ioksWeV0_xQ4rRnvm+hmeMdcBRzngNGA@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="f403045db5c8a73c400552a4f94a"
Subject: Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions
From: rasmus@mindplay.dk (Rasmus Schultz)

--f403045db5c8a73c400552a4f94a
Content-Type: text/plain; charset="UTF-8"

I think there is not much point in carrying on this debate.

Suffice it to say, I understand your arguments and your point of view, I
just don't agree with it - if this new feature produces closures, by my
understanding, it's alternate syntax for producing closures, and does not
constitute a new language feature, but rather an alternative to an existing
feature.

I'm a big non-believer in syntax alternatives for the same
language-features for various use-cases - picking between cosmetic options
slows me down while programming. I prefer languages that are consistent, in
the sense that each feature has a consistent syntax that works for every
use-case - and as such I would be happy with an improved syntax that fully
replaces the old syntax and works better for every use-case, but I would
view specialized alternate syntax, for the same feature, for certain
specific use-cases, as merely inconsistency and a symptom of missing
design. I admire languages with little, consistent syntax and
widely-applicable, highly-generalized features.

I understand if not everyone shares my point of view.


On Wed, Jun 21, 2017 at 11:19 PM, Rowan Collins <rowan.collins@gmail.com>
wrote:

> On 21/06/2017 15:04, Rasmus Schultz wrote:
> > > 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.
>
> I am perfectly happy for the feature to support all those things.
>
>
> > > 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.
>
> Then you are looking for something different from me. Again, I don't say
> you are wrong in this, I just don't share that desire, because I don't see
> the need to replace - or supplement - a working feature with a slightly
> different version.
>
>
> > 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.
>
> Again, this makes sense only given your starting point, which is not the
> same as mine.
>
>
> > 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.
>
> I mentioned this in my last e-mail without going into details, because it
> was discussed at length in the past, but perhaps you missed that, or have
> forgotten. In PHP, automatic capture of variables is absolutely not a
> natural scoping rule. Apart from the request super-globals - which many
> modern frameworks deliberately hide away from the user - every single
> variable has to be explicitly declared or imported into every single scope,
> throughout the entire language.
>
> The "use" clause on anonymous functions is not some weird wart for
> implementation purposes, it is the natural companion to the "global" and
> "static" keywords, and the natural consequence of not having a declaration
> to force a variable to be local. In PHP, all variables are local to a
> function by default, unless something explicitly says otherwise; there are
> certainly languages, notably JS, where the opposite is true, but that
> doesn't mean PHP is doing it wrong, or that mixing the two conventions in
> one language would be a good idea.
>
> I am willing to accept single-expression lambdas as an exception to this
> rule only because they are constrained to be short and simple; they read
> like an expression embedded in the outer scope, not a complete function in
> their own right.
>
>
> > A single-expression constraint on this feature would be a strange,
> arbitrary, annoying, unnecessary limitation.
> >
> > We didn't get it right the first time.
>
> I disagree with both of these statements. I don't consider this feature an
> attempt to fix something that went wrong, I consider it a new,
> complimentary, feature, for certain cases. Personally, I could live without
> it, but I have been convinced that it would be a useful short-hand for
> certain coding patterns.
>
>
> If we were to allow multiple-statement automatic-capturing closures, we
> would end up with 3 different ways to declare the same thing; using the
> fn() variant as an example:
>
> function($x) use($y) { return $x * $y; } // Long form; explicit return and
> explicit capture
> fn($x) => $x * $y; // Short form; implicit return and implicit capture
> fn($x) => { return $x * $y; } // Hybrid; explicit return, but implicit
> capture
>
> The short form is still constrained to be a single expression, because
> otherwise you can't omit the "return" statement; we would just have a third
> form that looks a bit like the short form, but isn't. So whatever syntax we
> choose, you won't be able to just add a semicolon and an extra line to turn
> a lambda expression into a function body.
>
> To me, the hybrid form is confusing and redundant; the fully shortened
> form makes certain simple closures considerably more concise, and remains
> reasonably readable. It is sugar for those use cases, just as the closure
> itself could be considered sugar for constructing an invokable object with
> private fields, and just as many other language features are sugar for more
> basic operations.
>
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--f403045db5c8a73c400552a4f94a--