04.01.2015, 04:58, "Brendan Eich" <[email protected]>:
Alex Kocharin wrote:
The code will be incorrect if you pass any regular object in there.
Why should symbol be any different?
For me, its throwing behavior is just another thing that could crash
server-side node.js process for no good reason.No good reason? Wrong.
Just because bugs pass without exception doesn't mean we must continue
the "tradition".
It isn't always a bug. People could cast something to a string for debugging purposes like this:
```
```
function log(anything) {
process.stdout.write(new Date().toJSON() + ' - ' + anything + '\n')
}
```
Right now it'll never throw. Well, unless you override `.toString()` to throw, which I've never seen to be done intentionally.
With throwing Symbols we'll have innocuous-looking code which will cause an exception. And since _javascript_ developers don't usually have a history of using throw..catch everywhere (some even avoid it for performance reasons), the consequences could be quite dire.
Thus, every single code snippet that use type casting will have to either be wrapped with try..catch or checked for `symbol` explicitly. Maybe we'll write libraries called "castAnythingToStringSafely" because of that (like json-stringify-safe is created because JSON.stringify throws). And it'll surely make things worse for the beginners who don't know language well enough to remember to add those workarounds everywhere.
So yes, I think that the existence of the errors you mentioned isn't a good reason to throw. There is no way for the interpreter to check developer intentions, and the casting can be used for good.
Also, if you want to prevent mistakes like `object['blah' + symbol]`, linters could be changed to forbid/warn about concatenation inside property names. It's their job to warn about suspicious behavior, _javascript_ spec should stay as simple as possible imho.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
