Open Question: can we restrict hosts to ensure their getIntrinsic is a superset of 262's?

[ljharb]

A host may need to be able to provide their own getIntrinsic function - in particular, if they want to provide additional intrinsics (such as web or node builtins).

Should we, and can we, require hosts' getIntrinsic to be an extension of 262's? Meaning, they would be forced to only provide added intrinsics, and not to remove any?

(this could be done in a similar fashion as the current spec intrinsic syntax - something like, "eval(x) === getIntrinsic(x) for all strings x that are an identifier/member expression, as if they were evaluated prior to user code".

How would this interact with 402's replacement of some 262 builtin functions? 402 of course could provide their own getIntrinsic, but theirs would likely fail the requirement as phrased above.

Another acceptable answer to the title question is "no".

[mhofman]

Maybe this could be expressed as an invariant? All intrinsics available when user code starts executing must be reachable through getIntrinsics (not just dot accessible things, but also syntax and other things reachable only procedurally). If an environment for some reason removes, replaces or doesn't provide a 262 defined intrinsic, it's allowed to reflect that in getIntrinsics. It would conceptually follow the way a polyfill may replace getIntrinsics to return the shimmed APIs before the rest of the user code executes.

[mhofman]

This does raise another question: what is the developer expectation for getIntrinsics? Should it only return 262 defined things, or all APIs available in the current Realm? Wouldn't the former produce a reification of standards organizations in the language that has been avoided so far?

[ljharb]

That invariant is exactly what I was thinking when I wrote this late last night, thank you.

I would like the developer expectations to be that it includes everything, and since web folks strongly insist that developers don't know or want to know the difference between 262 and HTML, i assume they would naturally want to provide their own getIntrinsic that adds Web APIs. However, I'm not sure how 262 could mandate that, since "intrinsic" is a 262 concept.

[mhofman]

The main problem I see is the notation difference between the specs. The developer would have to be able to refer to (and discover) a "built-in" without knowing which spec it's defined in.

[ljharb]

This reminds me of another thing I'd been thinking about - the % signs. I think these should maybe not be required, also for the reason you mentioned.

[mhofman]

A quick reading of Web IDL seem to show that all objects follow a similar structure with unique interface names (which may or may not be exposed), and a way to map that to ECMAScript objects, so it seem possible for the Web IDL spec to define how definitions translate to getIntrinsic as well.

[ljharb]

Currently we do not allow the % signs, and hosts are only allowed to add intrinsics.