4 ms·

Symbol has a toString method. It makes no sense to throw an error instead of just calling toString (like every other primative does). The whole point of making

Symbol has a toString method. It makes no sense to throw an error instead of just calling toString (like every other primative does). The whole point of making toString part of the Object prototype is that everything can be coerced into a string. Why are these new specs getting so error happy?

hdhzy 9y ago
Primitives themselves to not have methods, maybe you thought about primitive wrapper functions? Even then implicit conversion to string is special cased for each primitive (you can't call toString on null or undefined, see [0]). > Why are these new specs getting so error happy? I believe is called "fail fast, fail loud" principle. Remember Symbols are to be used as unique keys, if you accidentally mixed them with strings you'd lose this uniqueness. [0]: https://www.ecma-international.org/ecma-262/6.0/#table-12 https://www.ecma-international.org/ecma-262/6.0/#table-12
- deckar01 9y ago
  If you accidentally mixed an object with a string you would lose the ability to access it's properties, but that's not a good reason to throw an error. --- > primitive wrapper functions? I though that primatives would be unboxed so that their toString method could be called. Apparently not.
  - hdhzy 9y ago
    Symbols don't have any interesting properties to access. The problem is this case: s[t + ""] vs s[t] For all types they are the same because as we know in JS all properties (even array indexes) are converted to strings. But not for symbols, if you use symbol as "t" then implicitly calling toString would give you wrong result in first case. As this is clearly different from the rest of JS objects it's better to throw an error rather that silently proceed. > I though that primatives would be unboxed so that their toString method could be called. Apparently not. It's the other way around. Primitives do not have any properties so to call a method on it they are boxed before call. An example: Number.prototype.getBoxed = function () { return this} var x = 2..getBoxed() X will be a Number wrapper object, not a primitive.

hdhzy 9y ago

Primitives themselves to not have methods, maybe you thought about primitive wrapper functions? Even then implicit conversion to string is special cased for each primitive (you can't call toString on null or undefined, see [0]). > Why are these new specs getting so error happy? I believe is called "fail fast, fail loud" principle. Remember Symbols are to be used as unique keys, if you accidentally mixed them with strings you'd lose this uniqueness. [0]: https://www.ecma-international.org/ecma-262/6.0/#table-12 https://www.ecma-international.org/ecma-262/6.0/#table-12

deckar01 9y ago
If you accidentally mixed an object with a string you would lose the ability to access it's properties, but that's not a good reason to throw an error. --- > primitive wrapper functions? I though that primatives would be unboxed so that their toString method could be called. Apparently not.
- hdhzy 9y ago
  Symbols don't have any interesting properties to access. The problem is this case: s[t + ""] vs s[t] For all types they are the same because as we know in JS all properties (even array indexes) are converted to strings. But not for symbols, if you use symbol as "t" then implicitly calling toString would give you wrong result in first case. As this is clearly different from the rest of JS objects it's better to throw an error rather that silently proceed. > I though that primatives would be unboxed so that their toString method could be called. Apparently not. It's the other way around. Primitives do not have any properties so to call a method on it they are boxed before call. An example: Number.prototype.getBoxed = function () { return this} var x = 2..getBoxed() X will be a Number wrapper object, not a primitive.