> That's surprising. Within a moduleloader I would have thought that > same url meant the same static module. Across moduleloaders maybe not.
The problem is defining "same url." One option is that "same" means "identical string" but then when http://example.com/foo.html says: <script> module A = "http://example.com/lib.js";; module B = "./lib.js"; </script> the programmer would be tempted to think those are the same URL. And yet a server has access to its request URL and can deliver entirely different bits depending on exactly what was requested. So you could propose some sort of canonicalization that happens on the client side, and say "same" means "same canonicalized string." But then the semantics depends on some non-trivial algorithm that happens away from view of the programmer. > For the following scenario: > <script> > module ModA = "http://acme.com/moda.js";; > module ModB = "http://acme.com/modb.js";; > ... source > </script> > > Both ModA and ModB use a utility module - that is the moda.js and > modb.js files both contain: > module ModUtils = "http://widgets.com/modutils.js";; If they want to share a utility module, you pull it out into a place that's in scope for both ModA and ModB: <script> module ModUtils = load "http://acme.com/modutils.js";; module ModA = load "http://acme.com/moda.js";; module ModB = load "http://acme.com/modb.js";; ... </script> > But also, simple modules seem like 'traditional' modules. That is, if > a top level variable is declared in a C source file, that variable > occurs once in the resulting compiled image/program. Thus the source > files (modules) author can reason about the (shared state) of the > variable. I'm surprised to here you cite C as a precedent for modules, since C has no module system. All it has is #include, which is much harder to work with. The "load" semantics does still have the hazard of re-loading the same source (just as <script> does, BTW), but the scope is more tightly controlled; a loaded module is only sensitive to the modules in scope (no var-, let-, const- or function-bindings). Dave _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
