I'm new too, but don't think that's exactly how things get proposed here :)
Spec changes don't start with solutions - they start with existing problems
you're trying to solve. For example. In ES6 I might do
var res = ({
"hello" : () =>12, /* no fallback */"world" : () =>323, /* no fallback */
...
})[ myWord]
Or just an if, or other things. The cost of adding a keyword into the
language is big (you're breaking any code that uses that keyword as an
identifier which is a lot).
My suggestion is that you make a static analysis tool that warns people
about switch fallthrough and then advocate it. Tools like jshint/jslint
will warn you about it, using such tools can (and should IMO) be a part of
your build and release process.
I'm new too, but don't think that's exactly how things get proposed here :)
Spec changes don't start with solutions - they start with existing problems
you're trying to solve. For example. In ES6 I might do
```js
var res = ({
"hello" : () => 12, /* no fallback */
"world" : () => 323, /* no fallback */
...
})[ myWord]
```
Or just an if, or other things. The cost of adding a keyword into the
language is big (you're breaking any code that uses that keyword as an
identifier which is a lot).
My suggestion is that you make a static analysis tool that warns people
about switch fallthrough and then advocate it. Tools like jshint/jslint
will warn you about it, using such tools can (and should IMO) be a part of
your build and release process.
Thanks,
Benjamin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140209/0ca5caa9/attachment.html>
I'm new too, but don't think that's exactly how things get proposed here :)
Spec changes don't start with solutions - they start with existing problems you're trying to solve. For example. In ES6 I might do
var res = ({ "hello" : () => 12, /* no fallback */ "world" : () => 323, /* no fallback */ ... })[ myWord]Or just an if, or other things. The cost of adding a keyword into the language is big (you're breaking any code that uses that keyword as an identifier which is a lot).
My suggestion is that you make a static analysis tool that warns people about switch fallthrough and then advocate it. Tools like jshint/jslint will warn you about it, using such tools can (and should IMO) be a part of your build and release process.
I'm new too, but don't think that's exactly how things get proposed here :) Spec changes don't start with solutions - they start with existing problems you're trying to solve. For example. In ES6 I might do ```js var res = ({ "hello" : () => 12, /* no fallback */ "world" : () => 323, /* no fallback */ ... })[ myWord] ``` Or just an if, or other things. The cost of adding a keyword into the language is big (you're breaking any code that uses that keyword as an identifier which is a lot). My suggestion is that you make a static analysis tool that warns people about switch fallthrough and then advocate it. Tools like jshint/jslint will warn you about it, using such tools can (and should IMO) be a part of your build and release process. Thanks, Benjamin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140209/0ca5caa9/attachment.html>