Well-known Symbols + configurability/writability

[ljharb]

Would @@undefinedType also then be Symbol.undefinedType, per the established convention for well-known Symbols?

Would they thus be non-configurable/non-writable on Symbol? What about on Reflect.types? Would types itself similarly be non-configurable/non-writable on Reflect?

[alexweej]

Perhaps using the nomenclature of "well-known symbols" for this is incorrect, as they would already be available in Reflect.types.

I'd say the rules for the Reflect.types property descriptors should match whatever they are for Symbol with existing well-known symbols - I can't think of a reason why it should behave differently. As for the type property itself, I'm not really sure. It's hard to predict the needs of the polyfills of the future!

Do you have any ideas?

Thanks

[ljharb]

As a shim maintainer, I definitely would want to make sure I'm able to add new type symbols, but to Symbol and Reflect.types. The Reflect.type function itself seems easily polyfillable, provided that symbols exist.

However, Symbols can't be polyfilled - so in any engine without native symbols, how might I polyfill Reflect.type?

Is there a need to return symbols? Simply returning strings seems simpler, even if they were nicely stored in Reflect.types constants.

[alexweej]

I had considered leaving it open as to the exact value type returned by Reflect.type - so long as it was === comparable to the properties in Reflect.types and valid as property keys. That leaves exactly two options - string and symbol. I feel as if symbol is the right choice, shimmability issues aside. Shims have seemed to cope with the fact that Symbol.iterator is needed for the iterable protocol, and simply used strings with a big fat proviso. Is there any reason to believe that approach might cause more of an issue here?

(By the way, thanks for your great work on es6-shim. That thing makes my day job quite a lot more pleasant!)

[ljharb]

That's a fair point, indeed.