Angus Croll wrote:
Then I guess we need another survey.
What was the first survey?
Kevin's analysis was on code, using a tool to classify functions as
no-this/lexical-this vs. the rest.
"What does the JS arrow function proposal mean to you?
a) An abbreviated function syntax
b) A hard bound lexical |this| binding
c) Nothing"
This is all subjective and (without implementations to user-test)
prospective. A survey is not going to be helpful IMHO. Rorschach test...
I'd gladly be proved wrong but my guess is most JS developers who
don't answer (c) will answer (a). (I see plenty of supporting evidence
on Twitter). Thin arrow would be an excellent decoy for those who
expect (or want) just (a).
What do you mean by "decoy"?
This is all kind of twitter-ific, and so pretty much useless.
This is also in response to Kevin's suggestion that arrow syntaxis
barely more concise than regular function syntax. I don't think that's
the perception in the wider dev community, neither is it mine (in the
best case we save four ways - no function keyword, no braces, no
argument parens, no return stmt).
You mean where Kevin wrote:
"""
// On what basis is this:
this.initialize = () -> { ... };
// any better than this?
this.initialize = function() { ... };
There are a couple of characters saved, but it's less readable. Why
introduce new syntax for such dubious gain?
"""
with a space before the -> and one before { in both alternatives, and
with the parameter list costing the same no matter what, there are five
characters saved (' ->' vs. 'function').
Five is good, I like it (I like thin arrows and proposed them along with
fat arrows initially). But if this use-case is rare enough due to => and
method definition shorthand (combined with Object.extend or better where
possible), it may not be worth the added cost of ->.
What's the cost of adding ->? Mainly users having to remember when to
use which, and getting it wrong. That's not a trivial concern, and it
kept -> out of consensus at the last TC39 meeting.
Personally I expect I can get by using function keyword where using =>
will break my idioms - but its a bit much to expect everyone to
understand and react to these subtleties. I guess I'm trying to
anticipate future cowpaths and pave them before they make too much mess.
Doing nothing leaves the cows falling off the wrong-this cliff. Doing
something means adding syntax, there's no way to make a breaking change.
Adding two things instead of one makes not only two things, but the
problem of choice.
We may get -> yet, don't get me wrong. But it won't come from surveys or
twitter samples.
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
