On Aug 17, 2008, at 8:59 PM, Maksim Lin wrote: > Hi, > > In a comment on John Resigs blog about ES-Harmony, Hannes Wallnoefer > suggested that a simple module system he has implemented for helma-ng > [1] could be used for a future ES versions implementation. > > I think Brendan may have misunderstood the proposal as in a later > comment he said that : > "...Hannes points out how to solve it in-language, but that wheel is > (a) a leaky abstraction, which could be abused; (b) something no one > should have to re-invent." > > which I dont think is right
Which point, (a) or (b)? > since the way I understand Hannes > importModule() to work is that the code that is "imported" from the > corresponding js file is given a new object as its parent scope > (rather then the global one) and then that objects prototype is set to > the global scope. Tis then prevents the imported code from modifying > the "real" gloabl scope while still giving it read-access to it. > Hopefully I've explained it correctly, so apologies to Hannes if I > haven't. This does not work, since it is possible to mutate the properties of mutable objects named by properties on the prototype chain, not merely shadow prototype properties by assigning direct properties of the same name. But I'd like to hear more about Helma NG does it. > But I can't see how does that work as "in-language". To me it seems > that this requires the js implementation to do the above (messing with > the parent scope of the imported code) as it can't be done by the > application programmer in js unless you use a bunch of proprietary moz > API's like the mock example on the helma-ng page: Right. Magic not expressible in the language must be used, or there will be integrity problems, or to put it another way, abstraction leaks. > So instead why not have a new standard function importModule() that > does the above as part of the language spec? 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. 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. 3. Once having addressed the module and loaded its contents, how the module's provided names are required and accessed. 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. /be _______________________________________________ Es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
