feat: support explicit exports inspection

[guybedford]

Per discussion in the TG3 meeting today, it was determined that exports information would still be beneficial in this proposal for analysis.

This refactors the GetExportedNames concrete method to instead be split into a separate GetExplicitExportedNames and PopulateExportStarSet, where GetExplicitExportedNames can be called before linking.

We then expose a new namedExports() function on the module returning the string list of explicit named exports, and a starExports() function returning the star reexports imports of the form Import[].

This PR still doesn't provide any information about the bindings, to provide a general abstraction that can work for arbitrary cyclic module records.

Rendered spec at https://guybedford.github.io/proposal-module-instance-imports/build/.

[nicolo-ribaudo]

I don't think this should be an abstract method that subclasses have to implement, as given the list of explicit and star exports the behavior of PopulateExportStarSet shouldn't change per module type.

Subclasses only have to provide GetExplicitExportedNames and GetStarExports, and this shuold be a non-overridable abstract operation used somewhere in the module record or cyclic module record logic.

[guybedford]

This is correct - PopulateExportStarSet is defined for all cyclic module records, and that is how this is written.

More generally, better separating which methods are subclassed and which are defined on the base class in the spec text might help this ambiguity.

[guybedford]

Perhaps we should turn all abstract methods on abstract base classes that are defined for the base class into abstract operations taking a first argument of the base class type?

[nicolo-ribaudo]

Oh I could confused because PopulateExportStarSet's implementation's description says

The PopulateExportStarSet concrete method of a Source Text Module Record module

rather than cyclic

[nicolo-ribaudo]

Perhaps we should turn all abstract methods on abstract base classes that are defined for the base class into abstract operations taking a first argument of the base class type?

I think that if we expect other subclasses to have to re-implement their own logic then they should keep being abstract methods. If we expect only one valid possible implementation, then it should just be an abstract operation rather than something on the hierarchy chain.

[guybedford]

Ah thanks.

[nicolo-ribaudo]

Right now the hierarchy we have (including proposals) is

Module Record -> Synthetic Module Record
Module Record -> Cyclic Module Record -> Source Text Module Record
Module Record -> Cyclic Module Record -> WebAssembly Module Record

And in practice Module Record doesn't support any logic for dependencies (unless it's fully internal to that specific type of module record), while Cyclic Module Record is the one with dependencies support.

I think:

• GetExplicitExportedNames should be on Module Record
• GetStarExports should be on Cyclic Module Record, since it's about dependencies.
  • It defaults to returning an empty list, so that for example Wasm module don't have to explicitly define it.
  • Whenever we need to call GetStarExports, we check if we have a Cyclic Module Record. If we don't, we hard-code the result to an empty list.
• PopulateExportStarSet should be an AO defined inside GetModuleNamespace, since we only need it there and the "valid logic" is only one

[nicolo-ribaudo]

Or, as a (maybe better) alternative:

• We keep GetExportedNames on Module Record
• Cyclic Module Record has abstract methods GetExplicitExportedNames and GetStarExports
• Cyclic Module Record provides a concrete implementaton of GetExportedNames by using GetExplicitExportedNames and GetStarExports, rather than introducing PopulateExportStarSet

[guybedford]

I don't think it is so important to separate the concepts of modules with dependencies in the function structure, since this can be captured by an empty list return. So I've gone with the first suggestion under that refactoring with the only difference that the empty GetStarExports is on the base abstract module record.

[nicolo-ribaudo]

(deleted)