Many ECMA proposals solve problems with the language, that's a given. And you can't really change a well-established language without creating other problems. That's unavoidable and shouldn't be a barrier to progress. My concern with some of the proposals is the impact of these other problems isn't always given enough weight in determining if the change is worth it, https://twitter.com/#!/polotek/status/187219527459811330.
I think the recent concensus on fat arrow syntax is a good example to illustrate this. I think it's a decent proposal. I'm not sure I agree that "fixing" dynamic function context with syntax is absolutely necessary. But after talking to several people, I seem to be in the minority, so I can accept that this is happening. It's also a fairly simple proposal on it's face. If you use the
=> syntax, you'll get a function. And that function will have a few other "nice" properties, like automatic binding to the closest lexical
On the face of it, this seems like pure win. People want shorter function syntax and people want to worry less about
this. But this proposal has side effects, and more importantly it has affordances, that shouldn't be ignored. Most of these are expressed pretty well in this article by Angus Croll. In short, I'm concerned that people will use fat arrow, a lot, everywhere, and that's a problem.
Fat-arrow isn't just an alternative to normal function syntax. It's a new syntax that also introduces a completely new type of function. Functions that come from fat arrow have significantly different properties from normal functions. Some of the things you expect from normal functions are not applicable to fat arrow functions.
- Functions have dynamic
this, fat functions always have a
thisthat you can't anticipate.
- Functions can be dynamically dispatched with call/apply. Call/apply works with fat functions, but it will not change the context. Only pass arguments.
This is only a couple of items. There are several more differences that have to do with how the function body works. But these 2 have to do with functions that are passed around. These are differences that every developer who uses apis will have to deal with.
For one example, you if you take an object and mix it's methods onto your own object, you have to be aware of whether the functions are already bound. Otherwise you won't get expected behavior. Yes this is already a possibility with
How big a problem is this? I don't know. It's certainly more of an unknown than the misunderstanding of dynamic
But I could be way off base. This could be totally unfounded. Does anyone know how likely this type of thing is? How was it decided that the benefits of fat arrow outweight these potentially long-lasting detriments? Are there any plans to mitigate? These are the questions I'm left with once a "consensus" has been reached. I would love to have nothing better to do than pore over the es-discuss lists, but I just don't have the time. So I try to give my input on things as they gain enough popularity to get some publicity. And I don't always have constructive alternatives to present.
This is where I'm coming from when I scrutinize harmony proposals. Fat arrow isn't the only example; just the most recent. As an attempt to do more than just gripe, I think what would help is to publish concerns about the proposals and the rationale that minimizes those concerns. And even more helpful would be some talk about what criteria are concidered when evaluating proposals. When is battling current confusion more important than introducing new inconsistency? Why do we feel like the new weirdness will be less onerous?
I hope none of this feels like disparaging the work of standards body, and I hope it serves to clarify my views on progress. I don't know if I'll find more time to be a larger part of es-discuss and get in on these things earlier in the process. But I can promise not to be a person who just complains. Looking forward to feedback.