Claude Pache wrote:
Now, it will be argued that it would be a precedent to make such a distinction
between implicit and explicit coercion, for, until ES5, there is none.
Kind of there all along, as noted up-thread:
js> o = {valueOf(){return 42}, toString(){return 'haha'}}
({valueOf:function valueOf(){return 42}, toString:function
toString(){return 'haha'}})
js> String(o)
"haha"
js> ''+o
"42"
But I take your point.
But, precisely, pervasive implicit coercion is often thought to be a mistake in
the design of JavaScript (it hides bugs), while coercion in general is indeed
useful (e.g., for debugging purpose, as pointed Alex in this thread).
*Explicit* coercion in general is useful. What's "explicit"? It could be
console.log is an explicit-enough gesture. It does more than just
ToString on its parameters today, IINM (at least in some browsers).
Now, as we are evolving the language, it is good to limit the scope of the
bad implicit coercion behaviour (such as the abstract operation `ToString()` of
the spec), but to consolidate the functionality of the existing explicit
coercion functions (such as `String()`).
Yes, this is the rationale for ES6's symbol handling today.
If there is a need to directly expose the implicit coercion to string operation
to user code, `Reflect.toString()` is a natural fit for that, together with
`Reflect.toBoolean()`, `Reflect.toPropertyKey()`, `Reflect.toPrimitive(_,
hint)`, etc.
Yup; ES7 fodder at this stage.
I think it's very unlikely anyone will try to patch ES6 over the
trade-offs among consistencies that this thread has illuminated. Thanks,
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
