This is now an official project and will be eventually improved over there.
-
-
Save WebReflection/56d04ccb1e5b0e50c121 to your computer and use it in GitHub Desktop.
So far the caveats I notice are that Symbol.for
/Symbol.keyFor
won't work cross-realm, and that typeof
won't report "symbol" for any value. Also, could the string version of the Symbol conflict with a shimmed Symbol created in another realm?
not sure even natively for
and keyFor
would work cross realm (need to test) but I think there's no much I can do there (and x-realm is rarely a real-world problem). Conflicts are extremely highly improbable and using a DateTime won't give me much more security so ... not sure that's a real concern.
typeof returns a primitive as specs say, and string
is the only primitive that makes sense.
Transpilers could wrap it as typeOf()
and verify it's a Symbol
and since Symbol() instanceof Symbol
is false, as well as Symbol() instanceof Object
I don't think returning an Object
would be a better option than returning a string.
If you hold a Symbol
you should not have problems though, and since the whole logic is based on the assumption in order to retrieve symbols you need to getOwnPropertySymbols()
I guess we can live with the current state.
That being said, {__proto__: null}
and null
objects are IMO a bigger, probably not worth fixing, gotcha ... but that plus all other concerns are the reason we cannot possibly have a shim
but only a sham
for ES6
The spec requires them to work cross-realm but I'm not sure how engines are doing wrt to that compliance.
Right, I think that i'll have to be a sham. Looks great so far though!
Also, possibly a more reliable test for https://gist.github.com/WebReflection/56d04ccb1e5b0e50c121#file-symbol-js-L5 is if (typeof Symbol === 'function' && typeof Symbol() === 'symbol')
?
I think if getOwnPropertySymbols
is there we have to assume somebody else either patched upfront or the browser must support Symbol
natively. I don't see how that check can improve a sham, since we risk to overwrite other attempts that might be there and work as intended for reasons.
TL;DR I wouldn't go for that check, it's prolix for no advantages.
Following an attempt to make
__proto__
and null objects work with Symbols too. It does work apaprently with everything but{__proto__: null}
literals since these won't pass through the setter.