Implicit coercion of Symbols

[Andrea Giammarchi]

Alex, like I've said:

`log({__proto__:null})` and welcome crashes of the server, if that's a real
concern in this form.

Is it that wrong to assume that if `console.log({__proto__:null})` is
capable of handling non Objects and print a meaningful output, so should
any other logger implemented on user-land?

'cause logging a part there's still no case where implicit or explicit
Symbol cast makes any sense.

It's like `object['undefined']` where `undefined` is implicitly created by
some missed property which has been somehow problematic for long time.

A generic description-aware `Reflect.describe(genericObject)`like approach
seems way more useful for logging annd debugging purpose than a footgun in
the wild.

Regards



On Sun, Jan 4, 2015 at 3:41 AM, Alex Kocharin <alex at kocharin.ru> wrote:

>
> 04.01.2015, 04:58, "Brendan Eich" <brendan at mozilla.org>:
>
> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150104/113fab44/attachment.html>