Symbols on Module Namespace Exotic Objects

[GeorgNeis]

Module Namespace Exotic Objects have two (own) symbol properties.

[[Get]], [[GetOwnProperty]], and [[HasProperty]] for these have the ordinary semantics, but [[Delete]], [[Set]] and [[DefineProperty]] don't (e.g. [[DefineProperty]] always fails). This seems inconsistent and I'm wondering if it is a bug. (Also note that these symbols are set up as configurable).

[ajklein]

@bterlson Would love your input, it's hard to tell if this is a simple spec bug or if there's some deep intention in this inconsistency.

[ajklein]

@bterlson Would love your input, it's hard to tell if this is a simple spec bug or if there's some deep intention in this inconsistency.

[bterlson]

Seems like an oversight to me. I could see the current design making sense if the symbols were non-configurable, but instead they are configurable but impossible to change given the implementations of [[Delete]], [[Set]], and [[DefineProperty]]. These should learn to delegate symbol keys to the ordinary variants.

[bterlson]

Seems like an oversight to me. I could see the current design making sense if the symbols were non-configurable, but instead they are configurable but impossible to change given the implementations of [[Delete]], [[Set]], and [[DefineProperty]]. These should learn to delegate symbol keys to the ordinary variants.

[domenic]

I don't really have an opinion either way, but it seems like a plausible path is to just make the symbols non-configurable? It's a little strange that there would be two configurable properties on an object that otherwise acts somewhat "frozen".

[domenic]

I don't really have an opinion either way, but it seems like a plausible path is to just make the symbols non-configurable? It's a little strange that there would be two configurable properties on an object that otherwise acts somewhat "frozen".

[ajklein]

I was thinking that non-configurable would make more sense, too. Though if we do that I think we'd have to freeze the @@iterator method as well.

[ajklein]

I was thinking that non-configurable would make more sense, too. Though if we do that I think we'd have to freeze the @@iterator method as well.