Modules: compile time linking (was Re: Modules feedback, proposal)

Claus Reinke claus.reinke at talk21.com
Fri Apr 6 01:09:24 PDT 2012


>> So, assuming Math has no dependencies (just to make this shorter), the
>> sequence of events:
>> * Load Foo, convert to AST, find "from" usage.
>> * Load Math
>> * Compile Math
>> * Evaluate Math
>> * Inspect Math's exported module value for properties
>> * Modify the compiled structure for Foo to convert "import *" to have
>> local variables for all of Math's properties that are known, only at
>> this time (no funny dynamic 'with' stuff)
>> * Evaluate Foo
> 
> This is certainly the events I expect: is there an alternative? I suppose
> the module syntax could support moving Evaluate Math to just before
> Evaluate Foo. (a la a compiled language) The Math-level operations that
> created Math properties would not be known to Foo. That would be a major
> surprise to devs I think.

Several. The interaction of dynamic modules and static program
properties makes for an interesting design space - conveniences
you want to allow in one place quickly have unwanted consequences
in other places (for instance, I'm not convinced that James' scheme
does not permit to emulate 'with'). A few alternatives:

- you could try to determine Math's exported properties before
    compiling the importer

- you could try to split Math into an interface (that statically fixes 
    the exported properties) and an implementation (that allows
    dynamic instantiation of its interface); as long as the export 
    interface remains invariant, dynamic changes to Math do not 
    harm the dynamic importers static binding structure, even in
    the presence of 'import *'

- you could allow Math's properties to be determined at load
    time (runtime of the importer), but drop the convenience of
    'import *'; that allows Math's exported properties to change
    dynamically without affecting the static binding structure
    in the importer - essentially inlining a module interface in
    the import constructs (also, 'import *' is considered by many 
    as bad documentation, even in static module languages)

- ... 

Note that none of the three I listed quite matches the one given 
by James. My feeling is that ES6 modules aim for the first of
the alternatives I listed, with a dynamic fallback that does
not permit 'import *'. I agree about not permitting 'import *'
in combination with dynamically changing export lists, but
I would like to be able to use import destructuring with an
explicit import list even for this case.

Claus
 


More information about the es-discuss mailing list