I should also add that Ejscript (http://www.ejscript.org) successfully implemented the Program Unit abstraction from ES4 as the basis for a modules mechanism.
> > Several distinct functions are being mixed by importModule that > should be separated: > > 1. Addressing the module to be imported in an "external" storage > hierarchy, whether by URLs on the web or pathnames in a Unix > filesystem, etc. We use optional program URLs, but then also allow external resolution via an search path for modules. > > > 2. Whether loading of code from the addressed module is synchronous > or asynchronous with the call to importModule. Local file access > probably means importModule is synchronous, but this is wrong for the > Web browser embedding. We've assumed synchronous and don't currently have an async mechanism. > > > 3. Once having addressed the module and loaded its contents, how the > module's provided names are required and accessed. We have done this 2 ways now. First without namespaces where all module properties were enclosed in a module object that was added to the scope chain. More recently in keeping with the ES4 proposals, we used namespaces and module names corresponded to a namespace. Either way, both approaches have worked well. > > > Many times in TC39 we've discussed the module problem, and most agree > that 1 and 2 do not belong in the Ecma core language specification. > They belong (at least -- other embeddings matter too) in the HTML5 > spec. > > Item 3 is important, and there's already some work under way to > develop an idea based on PLT Scheme, which I'd like to propose for ES- > Harmony. Dave Herman wrote up a sketch at http://wiki.ecmascript.org/ > doku.php?id=proposals:modules. It has a "Caveat lector". > > >> [1] http://dev.helma.org/wiki/Modules+and+Scopes+in+Helma+NG/ > > This page links to http://www.mozilla.org/rhino/ > scopes.html#sharingscopes, which has further sections on sealing and > dynamic scope (which I remember reading long ago -- see the document > history). Again, without sealing of the "super-global", there are > integrity problems. > > Anyway, having a first class module system means not having to worry > about prototype and scope link cutting and re-welding, etc. This is > one reason why there must be life beyond ES3.1, which is to say, in > Harmony. One other thing modules effectively can solve is order of initialization over multiple program units. Michael O'Brien > > > /be > > _______________________________________________ Es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
