On May 10, 2011, at 4:27 PM, Isaac Schlueter wrote:
> On Tue, May 10, 2011 at 16:22, Oliver Hunt <[email protected]> wrote:
>> \ is a much more common lambda symbol in many languages, and i'm not sure
>> what the ambiguity would be in \{...} or \(...){...}.
>
> \(a,b,c) { a + b * c }
>
> That's cute.
Oliver still has a crush on Haskell.
I've mooted \ along with ƒ, etc. for a while. \ is bad for readability because
it's visually light, but worse, if we want named function expression shorthand,
then \u10A0(){} is a valid Unicode-identifier-char-named function expression.
Last time we talked about \ in TC39 for shorter function syntax it died hard,
IIRC.
>> I'm also really not happy with the concept of minor variances in syntax
>> having such dramatic impact the language semantics. All the fiddling with
>> |this| dramatically increases the complexity of the language, it doesn't
>> simplify it.
>
> I completely agree. It think any short-form function syntax should
> have the exact same semantics as the existing long-form. We've got
> .bind(obj). That's enough.
No, there are more efficient ways to implement something with dedicated syntax,
such as CoffeeScript's =>, and it comes up enough that '.bind(this)', ignoring
optimization difficulty, is too much.
The long-standing way to code lexical this is 'var self = this; ... function
(...) {... self ... }'. That won't go away, but it is also crying for a
shorthand.
What makes 'var self = this;' particularly bad is when the inner function is
named, and all its calls are via that unqualified name.
In such a scenario, ES5 strict's rule of binding |this| to undefined just
wastes the |this| parameter, and requires 'var self = this' or '.bind(this)' as
heavyweight workarounds.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
