Feed back and proposal for modules: allow importing ES5 files

[Alex Russell]

Hi Shaofei:

On Sep 22, 2012, at 6:29 PM, 程劭非 <csf178 at gmail.com> wrote:

> Hi, everyone,
> 
> 
> I noticed that current importing grammar will not work for ES5 files,
> I mean there is no way to import one or more es5/es3 files as a module
> and import variables from it.
> 
> The problem is:
> 1. There are no "export" keywords in a es5/es3 file, no variables are exported.
> 2. They might be using more than one files but current mudule grammar
> allows only one file as one module.
> 
> When the new standard(es6) comes out, I guess a big number of
> libraries need updating. And before they finish their work, I think we
> need a cheap solution for the new code(es6) to use old
> libraries(es5/es3) without modifying their code

One option here is for you to create an export "wrapper" for them, in essence a separate file that requires the old library be loaded which then exports the library's symbols through an export. Not pretty, but it requires no code changes for well-designed libraries.

> For the two points, I was considering two solution:
> 
> 1. Export all global variable by default.
> 
> Anonymous function could be used to protect the global namespace and
> most libraries are already using it. So I don't think "export" is
> needed.

You inadvertently identified why we need "exports": it's very difficult what is "global". In particular, what should be exported in the case of a file that includes:

var f = function(param) {
  thinger = param;
};

// ...

if (someGlobalConfigurationSetting) {
 f("howdy!");
}


?

> Exporting all global variable will not pollute the module's user's
> namespace for we still need "import" phase.

Perhaps instead of "global" you mean "the top-level IFFE"?

In that case, it's easier, but then it depends on the IFFE both being executed (it's not a static form here) and there being only one. Or is the suggestion that a file like this should export both a and b? And what will the value of c be?

// example.js

(function(p){
 var a = p;
})("hello");

(function(p){
 var b = p;
})("world");

var setValue = function(p){
  var c = p;
};

setValue("it's a sunny day!");
setValue("it's raining in London");

// end example.js


As you can see, at the limit, this creates some serious hazards for violating the data-hiding provided by closure-bound variables. Suddenly importers can not only see these internal names, but watch their values change!

> 2. Allow importing multiple files as one module.
> 
> This will completely decouple file and module. We need to modify the
> ModuleSpecifier grammar:
> 
> ModuleSpecifier ::= StringLiteral | Path
> ===>
> ModuleSpecifier ::= ( StringLiteral | Path ) ( "," StringLiteral | Path )*
> 
> With this, for example, if I'm using a RSA library like
> <http://www-cs-students.stanford.edu/~tjw/jsbn/>, I can do the
> following:
> 
> 
> import "jsbn.js","prng4.js","rng.js","rsa.js" as RSA;
> 
> If I want to use a module depend on jQuery1.3.2, I can do:
> 
> import "jQuery1.3.2.js","MyModule.js" as MyModule;
> 
> I've mentioned this idea in a reply, post it as a separate thread to
> get more feed back :-)


This is interesting. Do you have a proposed resolution mechanism for conflicts? We had such a thing in the old traits system for classes, but I don't think it has survived anywhere.

--
Alex Russell
slightlyoff at google.com
slightlyoff at chromium.org
alex at dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723