Modules: compile time linking (was Re: Modules feedback, proposal)
jrburke at gmail.com
Fri Apr 6 11:32:38 PDT 2012
On Fri, Apr 6, 2012 at 4:54 AM, Sam Tobin-Hochstadt <samth at ccs.neu.edu> wrote:
> The properties available to `Foo` are exactly the ones declared with
> `export` in `Math`. I don't think that should be a surprise to
> anyone -- that's what `export` is for.
> However, it is the case that the evaluation of `Math` and of `Foo`
> happen close together, even thought that doesn't make a difference in
> this case. It would potentially make a difference if there was some
> third module that imported from `Foo`.
A clarification: 'Math' may have been a bad example. I chose it since
it was something concrete where an "import *" on it made sense.
The order of events I listed was to allow "Math" to opt in to the
registering a module using a runtime API. I do not expect the real,
core "Math" lib to do so, just choosing some script example that makes
sense to do import *.
By executing a dependent module before finishing the compilation of
the module pulling in the dependency was to allow better interop with
a runtime module API, in a way that would give deeper name/type
checking and support an import * syntax, but not be like "with"
because any properties dynamically added to Math after Foo executes
are not available to Foo (assuming dynamically adding properties to
Math were even allowed).
Since the import * burns in the local variables during the final AST
modification of the module after evaluating its dependency, deeper
name/type checking can be done besides the top level exports, since
the dependency has actually been evaluated.
More information about the es-discuss