Modules: compile time linking (was Re: Modules feedback, proposal)
claus.reinke at talk21.com
Fri Apr 6 02:04:05 PDT 2012
I just noticed that James' original email had two more items:
>>>* The 'Math' module is evaluated before Foo is evaluated.
>>>* Only the properties on Math that are available at the time of Foo's
>>>execution are bound to local variables via the "import *".
which puts it in line with the first option I mentioned, contrary
to my final paragraph. Also, he seems concerned mostly with
static modules, not dynamic ones.
>>> 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.
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss