> There is quite a bit of literature on “2nd class” module systems, but
> most of it is from a period before first class modules became the
> primary modularity research interest. I’ll see if I can dig up some
> references to papers that may be helpful.
That would be great. I'll be glad to include them in a "references" section on
the strawman page. I should also throw in some references to some languages
that have similar or related module systems.
> One of the points that I recall is the importance of not entangling
> “module management” with “configuration management”. In this context,
Absolutely. Like in Ihab and Kris's proposals, the intention was to separate
out the notion of module ID's and module ID resolution in order to allow
host-dependent behavior. The examples I gave were to give some concreteness,
but the actual mechanism(s) for resolving those identifiers would not be (at
least fully) specified in the language itself.
> As a more concrete example, a “program” might be logically composed of
FWIW, I tried using the word "application" instead of "program" for this use,
to distinguish from the Program non-terminal in ES <= 5.
> Module management becomes entangled with configuration management when
> configuration management information is embedded within the actual
> module definitions. When this occurs, configuration changes require
> the modification of the actual source code of modules.
Well put, and I agree. Still, as you mentioned in the F2F, it's critical to
make the common cases as absolutely convenient as possible. In that light, it
might be ideal to allow imports to specify their dependencies *either* directly
or indirectly through some mediating entity. That way, simple one-offs could be
written like:
import 'http://json.org/modules/json2.js' as JSON;
and more mature applications could write:
import org.json.JSON as JSON;
with some top-level table that indicates how to interpret org.json.JSON.
I don't feel this strawman depends too deeply on the exact nature of the
ModuleSpecifier non-terminal, syntactically or semantically. In many ways it's
probably necessary *not* to specify at all for ES. But independent of what goes
into any eventual standard, it does have to be compatible with actual
implementations, so I'm glad you're bringing up these points.
> As an alternative my suggestions is that we completely avoid using
> strings within ECMAScript source code to (statically) identify
> modules. Instead, modules might be identified (in both Module
> declarations and ImportDeclarations ) as any of the following
> alternatives 1) a simple identifier, 2) a sequences of dot separated
> identifiers (my current preference), or 3) a sequence of identifiers
> separated by some other delimiter such as “::”. These identifiers
> populate a single module name space that is distinct from the
> EnvironmentRecords used for normal identifier resolution.
Syntactically, I don't have strong feelings, as long as it's statically
resolvable. I agree that these live in a separate namespace, entirely
independent of the lexical environment. (If I didn't mention it, that was meant
to be part of the strawman.)
> However, while I think that the semantics of dynamic processing a
> Module declaration (for example, via eval…) needs to be well specified
> in the ECMAScript core semantics, it is less clear to me that
> loadModule needs to be part of the standard ECMAScript library.
Great point-- agreed. Consider loadModule to be a plausibility argument. I'll
work on identifying which parts of the strawman are "suggestive" rather than
"strawman-normative". :)
> Externally locating and retrieving a container of an Application
> declaration seems like an inherently implementation or environment
> specific action and perhaps the definition of an API like loadModule
> should be relegated to environment specific libraries (eg a browser
> API)).
Indeed.
Thanks for the feedback-- keep it coming!
Dave
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
