| 16:43 | <Michael Ficarra> | module namespace exotic objects should define their [[SetPrototypeOf]] as the immutable prototype exotic object [[SetPrototypeOf]] so that they're considered immutable prototype exotic objects |
| 16:49 | <Michael Ficarra> | I'll send a PR |
| 17:00 | <bakkot> | ... but why |
| 17:00 | <bakkot> | you will also need to update the note:
|
| 17:05 | <Michael Ficarra> | yeah there will be a couple places to update |
| 18:01 | <shu> | why are you doing this? |
| 18:04 | <shu> | i'm not sure what value immutable prototype exotic objects provide, other than as a shorthand for "it's like a normal object, except [[SetPrototypeOf]] is overridden" |
| 18:04 | <shu> | and your proposed change would make it also lose that notion |
| 18:04 | <shu> | since module namespace exotic objects override the other internal methods itself |
| 19:05 | <ljharb> | is there any reason https://tc39.es/ecma262/2025/#sec-createiteratorfromclosure requires generatorPrototype to be an Object, vs "an Object or null"? (or is the reason just, we don't send it null ever) |
| 19:07 | <shu> | not that i recall, but having the narrowest type for how it's used is something we generally do, yes |
| 19:08 | <shu> | for this particular AO, creating a generator object with a null prototype seems like it'd always be an error, no? |
| 19:40 | <Michael Ficarra> | it just means "[[SetPrototypeOf]]" has this special behaviour, which is also true of module namespace exotic objects |
| 19:41 | <Michael Ficarra> | if you asked anyone whether module namespace exotic objects were immutable prototype exotic objects, they would say yes, but due to a technicality in the way we specified it, it's not actually the case |
| 19:42 | <Michael Ficarra> | because it's not "the same" definition, even though it's defined using the same steps |
| 20:29 | <shu> | i think the answer "anyone" would respond with is "what are immutable prototype exotic objects?" |
| 20:34 | <bakkot> | as one of the very few people in the world who actually does have familiarity with the term, I would have told you it refers to Object.prototype, and possibly the HTML windowproxy |
| 20:35 | <bakkot> | namespace exotic objects have immutable prototypes but "immutable prototype exotic object" means Object.prototype to me |
| 20:56 | <shu> | if anything i'd rather we remove the concept of "immutable prototype exotic object" at all |
| 21:07 | <Michael Ficarra> | An object is an immutable prototype exotic object if its [[SetPrototypeOf]] internal method uses the following implementation. Its other essential internal methods may use any implementation, depending on the specific immutable prototype exotic object in question. |
| 21:07 | <Michael Ficarra> | it doesn't get much more clear than that |
| 21:07 | <Michael Ficarra> | that should apply to module namespace exotic objects |
| 21:08 | <Michael Ficarra> | PR is here: https://github.com/tc39/ecma262/pull/3611 |
| 21:18 | <shu> | it does get clearer: you don't need to think of them as a special object |
| 21:19 | <shu> | you just think of them as having a certain implementation of [[SetPrototypeOf]] |
| 21:19 | <shu> | i don't see what we get out of assigning a term to objects with that certain implementation |
| 21:20 | <shu> | like, the information you're trying to communicate is "[[SetPrototypeOf]] has this behavior". why not communicate that directly instead of indirectly by first defining "the set of objects with [[SetPrototypeOf]] with that behavior is called X"? |
| 22:12 | <Michael Ficarra> | with the PR we do both |
| 22:12 | <Michael Ficarra> | we link to the implementation and we give those kinds of objects a name |
| 23:01 | <shu> | i am questioning the value of giving those kinds of objects a name |
| 23:02 | <Michael Ficarra> | given that we already do, we should use it for all the things it describes |
| 23:02 | <Michael Ficarra> | it's in a very weird state right now where the term applies to only some of the things that have the property |
| 23:03 | <Michael Ficarra> | I would make this change and then consider the usefulness of the term later |
| 23:03 | <Michael Ficarra> | but I think the term is probably something that at least the committee finds useful |
| 23:03 | <shu> | i have doubts about that the status quo is really that desirable |