importModule followup

Maksim Lin maksim.lin at
Sun Aug 17 20:59:15 PDT 2008


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 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.

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:

  // set reference to global object
  var __global__ = __global__ || this;

  function include(script, as) {
    var scope = new Object();
    scope.__parent__ = null;
    scope.__proto__ = __global__;
    // scope is now a top level scope that inherits
    // from the global, shared top level scope
    this[as] = scope;

So instead why not have a new standard function importModule() that
does the above as part of the language spec?

Or perhaps it really belongs as part of the Host implementation and
should be part of the DOM or something, but then if thats the case,
what is the case for having package/module functionality in the ES
spec at all?



More information about the Es-discuss mailing list