Editorial: Add a %MapProto_set% intrinsic object.

[Ms2ger]

This is to be used in WebIDL.

[ljharb]

If #1376 lands, then you’d be able to reference %Map.prototype.set% without needing an explicit entry in the intrinsics table. For WebIDL, would that obviate the need for this PR?

[annevk]

I think it would. What implementers lose though is the centralized knowledge of which need to be available as such and which can be thrown away if modified.

[zenparsing]

@annevk As a downstream spec author, how important is it to have that centralized knowledge? We've been discussing paring down the intrinsics table using the internal syntax @ljharb mentioned, but you seem to argue for keeping it?

[ljharb]

I think it’s very hard to ever remove any intrinsic from this spec; even if the web stopped using it, how do we know no other layered specs or engine haven’t used it?

[domenic]

I tend to agree that that centralized knowledge isn't necessarily something to maintain in the spec level.

[allenwb]

I think it would. What implementers lose though is the centralized knowledge of which need to be available as such and which can be thrown away if modified.

That is exactly the reason that table was introduced into the ES6 spec. Prior to that in ES5 stylized language ("the original built-in value of Foo") was introduced into ES5 to clarify when an intrinsic value was needed. Prior to that it was ambitious whether an intrinsic value or the current bound value was to be used. But in ES5 a search of the specification was still required for an implementor to identifying which of the hundreds of built-in objects needed to be registered for guaranteed availability. Such a search is impossible if there is an open-ended set of dependent specifications that may need to access various built-ins.

Removing the table might make life easier for the editors but it does not make the specification more useful for implementors. The need to explicitly add new table entries also provides notification to the editors that an layered spec. or a proposed extension needs such access. It's always good to review such new usages to make sure they are valid or make sense from a more global perspective. Making something a realm intrinsic simply via naming convention makes it more likely that the usage could slip without review.

In summary, I think that removing the table simply for editorial convenience is a bad idea. You shouldn't do it.

[jmdyck]

If an implementer were to simply retain every intrinsic (i.e., treat every intrinsic as if it were "well-known"), would there be a significant downside?

[jmdyck]

(By the way, PR #1105 has a similar discussion.)

[ljharb]

@allenwb there are no plans to remove the table, or even to remove any of the existing entries; #1376 is an attempt to prevent its unbounded growth by requiring a table entry for each “root object”, but allowing chaining syntax to be used for anything that is accessible off of it in an unmodified realm. Your thoughts on that PR would be appreciated.

[jmdyck]

What implementers lose though is the centralized knowledge of which need to be available as such and which can be thrown away if modified.

As far as I can see, the ES spec doesn't actually say that Table 7 is a list of such intrinsics. As @littledan says: "I think the set of things that actually needs to be kept around in a real implementation will differ somewhat from what the spec lists (in both directions, including some additional things and leaving out some things)."

[annevk]

@zenparsing I'm not trying to argue, I was trying to make sure any eventual decision takes that consideration into account. I personally do prefer such explicitness for the reasons @allenwb laid out, but I can see the reasons for not willing to maintain such a registry too.

@jmdyck that thread continued quite a bit though, with various interpretations of its purpose and various things still unaddressed (e.g., intrinsics versus abstract operations, existing entries without a clear purpose).

[jmdyck]

that thread continued quite a bit though, with various interpretations of its purpose and various things still unaddressed

Yeah, I wasn't suggesting that 1105 had all the answers, just that it was discussing some of the same questions.

(It would have been nice to have a single place for the meta-discussion, oh well.)

[Ms2ger]

If #1376 lands,

It hasn't in the last 27 days; is it likely to land in the next 27?

[ljharb]

@Ms2ger the last 27 days included the holiday season; I’m hopeful that yes, it will.