On 17 January 2012 03:12, David Herman <[email protected]> wrote: > The only way to avoid refactoring pitfalls entirely is to avoid making any > changes in the language altogether.
I disagree, see my previous reply. It depends on what class of refactoring pitfalls you are talking about. > I believe we should do our best to avoid refactoring pitfalls as much as > possible, but I can live with a few (e.g., differing scope rules for > block-local functions, arguments aliasing, eval scoping, special cases for > destructuring + arguments) in exchange for the drastic improvement to > developers' cognitive load, the vastly improved adoption story, and the unity > of the spec. I'll repeat a point I've tried to make earlier. Having all (or the majority of) new features in both classic and extended mode does _not_ decrease cognitive load, nor unity of the spec. That's an illusion (which, admittedly, may work with developers, but it's cheating on them). Instead, there are more cases everybody has to worry about. Language complexity will be _increased_, and "unity of the spec" is merely a euphemism for having to spec ugly corner cases that you didn't have to spec otherwise. Let me put it a different way. One lesson I've learned over years is: - context-dependent lexical syntax is a bad idea. - context-dependent grammatical syntax is a bad, bad idea. - context-dependent static semantics is a bad, bad, bad idea. - context-dependent dynamic semantics is a bad, bad, bad, bad idea. - context-dependent library semantics is... well, you get the idea... There already is enough of that in JS that we cannot get rid of. I'd prefer not to combinatorially enlarge that set. And the implicit, scoped opt-in idea is on the 4th level of badness. ;) And with that, I gonna shut up. /Andreas _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
