An attempt to polyfill Symbol for ES5 compatible engines

Symbol.md

This is now an official project and will be eventually improved over there.

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.