On May 10, 2013, at 7:18 AM, Andreas Rossberg <rossb...@google.com> wrote:
> Can you explain how one form of module declaration is easier to "move
> around"? In a single script there surely is no difference.
Clients of a module can write:
import { f } from "foo";
and regardless of how the module "foo" is shipped -- in a separate file or with
an explicit module declaration in a bundled file -- the client code is
unperturbed. This means that a single package can easily be deployed with any
number of files without affecting client code.
> OK, perhaps I am under wrong assumptions about the semantics of
> ondemand. I assumed that when you first import a module that has been
> registered via ondemand, the respective script will be executed,
> recursively, and then linking of the outer script continues, taking
> the updated loader environment into account.
OK, this is a big difference between your imagined system and the current one.
The current system does not execute modules until dependencies have been
fetched and linked -- I explained this in the March meeting. (The .ondemand
method is sort of a distraction; it's nothing more than an API convenience
layered upon the underlying resolution hook.) This means that cyclic
dependencies work, and dependencies are resolved statically across multiple
files, causing a full static dependency graph to be concurrently fetched.
What you describe has a sharp distinction between packages and modules, where
packages cannot have cyclic dependencies, must be dynamically loaded and
registered, and are composed only of lexically scoped modules. What this seems
to mean is, to implement a package (such as a library, application, or
component of an application), you have to choose from one of three options:
- implement the package in one big file.
- implement the package in multiple files via some extension to ECMAScript
(e.g., include) that requires a tool to assemble it back together in a single
file with only lexical modules.
- split the package into smaller packages, each comprising only one or at least
very few modules, forgo any cyclic dependencies, and effectively get little to
no benefit from lexical modules.
Please do tell me if I'm missing something, because all of the above scenarios
seem obviously impractical. In particular, it's a necessity that the system
should work well out of the box, with no additional tools. Obviously large and
sophisticated applications will be willing to buy into additional
infrastructure, but you should certainly be able to put a package's modules in
separate files without build tools.
Dave
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
