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.coll...@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
>
>
