<span class="" style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">Hi Shaofei:</span><br><div><font class="" color="#500050" face="arial, sans-serif"><br></font></div><div><font class="" color="#500050" face="arial, sans-serif">Inline:</font></div>

<div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 24, 2012 at 7:22 AM, {oD <span dir="ltr"><<a href="mailto:csf178@gmail.com" target="_blank">csf178@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

Thank you for replying, Alex.<br>
<br>
Replied inline.<br>
<br>
2012/9/24 Alex Russell <<a href="mailto:alex@dojotoolkit.org">alex@dojotoolkit.org</a>>:<br>
<div class="im">> Hi Shaofei:<br>
><br>
> On Sep 22, 2012, at 6:29 PM, {oD <<a href="mailto:csf178@gmail.com">csf178@gmail.com</a>> wrote:<br>
><br>
>> Hi, everyone,<br>
>><br>
>><br>
>> I noticed that current importing grammar will not work for ES5 files,<br>
>> I mean there is no way to import one or more es5/es3 files as a module<br>
>> and import variables from it.<br>
>><br>
>> The problem is:<br>
>> 1. There are no "export" keywords in a es5/es3 file, no variables are exported.<br>
>> 2. They might be using more than one files but current mudule grammar<br>
>> allows only one file as one module.<br>
>><br>
>> When the new standard(es6) comes out, I guess a big number of<br>
>> libraries need updating. And before they finish their work, I think we<br>
>> need a cheap solution for the new code(es6) to use old<br>
>> libraries(es5/es3) without modifying their code<br>
><br>
> 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.<br>


<br>
</div>I tried to find a way to make a wrapper but I failed.<br>
<br>
Consider I have a file<br>
// mylib.js<br>
<br>
//depends on jQuery<br>
$(......).attr(......)<br>
<br>
When importing it as a library<br>
<br>
//There is no way to add $ to it's scope<br>
//except polluting the global object<br>
import "mylib.js" as myLib;</blockquote><div><br></div><div>Right. What I'm suggesting isn't that you'll be able to prevent the global from being augmented, rather that if your goal is to take an *already well behaved* library and wrap it with modules, that's possible.</div>

<div> </div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>

<div class="h5">
>> For the two points, I was considering two solution:<br>
>><br>
>> 1. Export all global variable by default.<br>
>><br>
>> Anonymous function could be used to protect the global namespace and<br>
>> most libraries are already using it. So I don't think "export" is<br>
>> needed.<br>
><br>
> 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:<br>
><br>
> var f = function(param) {<br>
>   thinger = param;<br>
> };<br>
><br>
> // ...<br>
><br>
> if (someGlobalConfigurationSetting) {<br>
>  f("howdy!");<br>
> }<br>
><br>
><br>
> ?<br>
><br>
>> Exporting all global variable will not pollute the module's user's<br>
>> namespace for we still need "import" phase.<br>
><br>
> Perhaps instead of "global" you mean "the top-level IFFE"?<br>
><br>
> 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?<br>


><br>
> // example.js<br>
><br>
> (function(p){<br>
>  var a = p;<br>
> })("hello");<br>
><br>
> (function(p){<br>
>  var b = p;<br>
> })("world");<br>
><br>
> var setValue = function(p){<br>
>   var c = p;<br>
> };<br>
><br>
> setValue("it's a sunny day!");<br>
> setValue("it's raining in London");<br>
><br>
> // end example.js<br>
><br>
><br>
> 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!<br>


<br>
</div></div>Perhaps I'm not expressing clearly.(Sorry I'm not a native speaker.)<br>
<br>
I'm not saying that  we should export variables inside a IFFE.<br>
<br>
I mean that :<br>
<br>
//example.js<br>
<br>
var $;<br>
// for ES5 $ should be a property of global object,<br>
//I mean even without “export”, Module instance object<br>
//should have a binding for "$" when example.js imported<br>
//as a Module<br>
<br>
(function(){<br>
<br>
    $ = function(){<br>
    }<br>
    // $ could be changed<br>
<br>
    var $2 = function(){<br>
    }<br>
    // $2 will not be imported<br>
    // because it's in a IFFE.<br>
})();<br>
<br>
-----------------------------------------<br>
// somewhere<br>
// Variant A:<br>
import "example.js" as myQuery;<br>
import $ from myQuery;<br>
<br>
// Variant B:<br>
module myQuery = "bar.js";<br>
import $ from myQuery;<br>
<br>
//$ should be able to be used here</blockquote><div><br></div><div>I see. It's unclear, then, how this sort of thing works with conditionals and "this" assignment. E.g.:</div><div><br></div><div>// conditional.js</div>

<div><div>if (false) {</div><div>  var thinger = "whatevs";</div><div>}</div><div><br></div><div>print(thinger); // undefined</div><div><br></div><div>this.thinger = "whatevs";</div><div><br></div><div>

print(thinger); // "whatevs"</div></div><div>// end conditional.js</div><div><br></div><div>I think you can make a strong argument that since it's the user of the module that is deciding how to use it, "this" assignment not having the normal side-effects is fine...although I expect legacy scripts to point to a "this" which isn't module scope but rather is a global. The "var" thing points to a deep vein of difficulty -- notably the inability to reason about the exports in a reliable way.</div>

<div><br></div><div>I'm curious what others thing about this.</div><div> </div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div class="im">
><br>
>> 2. Allow importing multiple files as one module.<br>
>><br>
>> This will completely decouple file and module. We need to modify the<br>
>> ModuleSpecifier grammar:<br>
>><br>
>> ModuleSpecifier ::= StringLiteral | Path<br>
>> ===><br>
>> ModuleSpecifier ::= ( StringLiteral | Path ) ( "," StringLiteral | Path )*<br>
>><br>
>> With this, for example, if I'm using a RSA library like<br>
>> <<a href="http://www-cs-students.stanford.edu/~tjw/jsbn/" target="_blank">http://www-cs-students.stanford.edu/~tjw/jsbn/</a>>, I can do the<br>
>> following:<br>
>><br>
>><br>
>> import "jsbn.js","prng4.js","rng.js","rsa.js" as RSA;<br>
>><br>
>> If I want to use a module depend on jQuery1.3.2, I can do:<br>
>><br>
>> import "jQuery1.3.2.js","MyModule.js" as MyModule;<br>
>><br>
>> I've mentioned this idea in a reply, post it as a separate thread to<br>
>> get more feed back :-)<br>
><br>
><br>
> 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.<br>
<br>
</div>Do you mean name conflict?<br>
<br>
If "jQuery1.3.2.js" and "MyModule.js" are all ES5 style (no module<br>
system used). There should not be any conficts or they will not work<br>
in ES5.<br></blockquote><div><br></div><div>That's not true. One will simply overwrite the other. There's a default resolution mechanism there (last wins). Let bindings and module forms create a new static early-error scenario that we didn't have before. </div>

<div> </div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
This is different from<br>
import "jQuery1.3.2.js" as jQuery;<br>
import "MyModule.js" as MyModule;<br>
<br>
The declaration<br>
<div class="im">import "jQuery1.3.2.js","MyModule.js" as MyModule;<br>
</div>should behave like importing a file just like "jQuery1.3.2.js" and<br>
"MyModule.js" are copied together.</blockquote></div><br></div>