Hi Kris, Thanks for your thoughts; I'll keep reading but I do want to respond to a couple points that I don't think are quite accurate.
> The one step forward comes from handling cyclic dependencies > elegantly. If I am correct, this is the feature we gain from "second > classness" and from not basing the module system on a better "eval". I don't agree with this summary. First of all, you don't have to base any module system on eval. By keeping modules second class, we get a number of benefits, not just handling cyclic dependencies. (In fact, cyclic dependencies can be handled nicely in a first-class module system as well.) One of the benefits of second-class modules is the ability to manage static bindings; for example, import m.*; is statically manageable. Allen has made some good points about how second-class modules are a good fit for the programmer's mental model of statically delineated portions of code. At any rate, cyclic dependencies are not the central point. > The loader proposal reintroduces the idea of a "better > eval", being simply a hermetic evaluator that collects a working set > of modules, links them, and executes them. It's more than eval -- e.g., it provides load hooks to manage resource fetching and even allow transformation -- but yes, it does provide a more controlled eval. > Because all of the Rhino codebase contains fully qualified names in > every file, refactoring Rhino to contain and link against alternate > names is onerous, and alternately creating a parallel universe for the > minifier fork is onerous, so these things are simply not done. I don't see how this problem applies to simple modules. Because modules are referred to as bound names, rather than as fully-qualified names or URL's, it's easier for separate projects to share common components. They can even share the same module under different names, since module names can be rebound (module NewName = OldName) and modules in separate files can be loaded with different names (module Foo = load '...some url...'). > The original Simple Modules proposal was only sufficient in the small. > The Loaders proposal addresses the large. That's not true. Loaders are about isolation. I agree with you that conceptually, there's a level of granularity that consists of a set of modules, which is often what we mean by "package," at least in common usage (if not the particular meaning of that term in a given language). But the idea of nested/hierarchical modules is that modules scale to the large by simply making modules that consist of nested modules. > It does not yet enable linking to other working sets > of internally consistent modules This is also not true; the ability to attach modules to module loaders (as well as the dynamic evaluation methods) makes it possible for separate module loaders to communicate. However, loaders aren't about linking multiple working sets, but rather providing isolated subspaces. (One use case I sometimes use is an IDE implemented in ES, that wants to run other ES programs without them stepping on its toes.) > Another feature of Simple Modules is that it preserves the > "equivalence by concatenation" property of existing "script" tags, > while liberating the scripts from being sensitive to the order in > which they are concatenated. This is in conflict with the goal of > removing autonomous module blocks. I don't quite understand this, and I'm glad you bring up the issue of latency and plugging into the browser semantics. I believe we're at least partway to the answer, but I won't believe we've solved it till I really see it go all the way through. That said, I am also not convinced that a) the <script> tag is going away any time soon, or that b) we necessarily need to solve these problems in the context of a module system. > Simple Modules, at present, will not sufficiently assist people > constructing applications and APIs by composing non-coherent groups of > name spaces produced by non-cooperating groups of developers. I'm not convinced of this point. If someone doesn't want to share their code, there's nothing we can do to make them do so. But if they do want to, the simple modules proposal explicitly *solves* the problems of Java-like systems where everything is hard-wired. Instead, modules are given lexically scoped names, and can even be deployed without naming themselves; both of these features make it far easier to share code between different teams. Dave _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
