Is %AbstractModuleSource% synchronously reachable from script?

[bathos]

On first read it seemed like it wouldn’t be possible to synchronously obtain a reference to %AbstractModuleSource% during script evaluation. If so, it would be the first intrinsic object for which that’s true. This can create problems for virtualization strategies that depend on “first-run-code” status to capture intrinsics and prepare an environment for other code, e.g. “initialization” scripts passed to ShadowRealm.prototype.evaluate prior to running other scripts. Similarly it would seem to prevent “hardening” strategies that freeze intrinsics up-front.

...but maybe it is reachable? %AbstractModuleSource% is said to “[act] as the abstract superclass of the ModuleSource” — and while “ModuleSource” isn’t linked and doesn’t seem to be defined in the current spec text, the readme for this repo makes it sound like that’s supposed to be another new intrinsic. Is %ModuleSource% being specified in another related proposal or is it part of this one and just not in the spec yet? Will it be exposed by a regular global property?

[nicolo-ribaudo]

It is not reachable without using platform-defined objects at all, which made it possible to make an exception for this particular case.

In an ECMAScript-only environment you cannot freeze it, but code cannot get access to this mutable object anyway.

ModuleSource will be introduced by a fire proposal adding reflection for JS modules.

[bathos]

It is not reachable without using platform-defined objects at all, which made it possible to make an exception for this particular case.

Ah, got it!

(I’m guessing it follows that hosts implementing its derived constructors would typically be expected to expose those as globals? )