3 ms·
Primitives themselves to not have methods, maybe you thought about primitive wrapper functions? Even then implicit conversion to string is special cased for ea
by 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 agoIf 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 agoSymbols 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.