On Wed, Jun 27, 2012 at 2:21 PM, Sam Tobin-Hochstadt <sa...@ccs.neu.edu> wrote:
> On Wed, Jun 27, 2012 at 3:37 PM, James Burke <jrbu...@gmail.com> wrote:
>> On Wed, Jun 27, 2012 at 11:56 AM, Sam Tobin-Hochstadt <sa...@ccs.neu.edu>
>> wrote:
>>> Then we can use the module like this:
>>>
>>> System.load("add_blaster", function(ab) { return ab.go(4,5); })
>>>
>>> or, since we know that "add_blaster" is a local module:
>>>
>>> let { go } = System.get("add_blaster");
>>> go(9,10);
>>>
>>> or, if we put the call to `System.set` in the previous script tag, we
>>> can just do:
>>>
>>> import go from "add_blaster";
>>> go(2,2);
>>>
>>> At no point here did we have to write a module system.
>>
>> This is not usually how we have found loading to be done in AMD.
>> 'add_blaster' is usually not loaded before that import call is first
>> seen. Call this module foo:
>>
>> import go from "add_blaster";
>>
>> The developer asks for foo first. foo is loaded, and parsed.
>> 'add_blaster' is seen and then loaded and parsed (although not sure
>> how 'add_blaster' is converted to a path…):
>>
>> add_blaster calls the runtime:
>>
>> System.set("add_blaster", { go : function(n,m) { return n + m; } });
>>
>> What happens according to the current modules proposal?
>
> I'm not quite sure what you're asking. If the question is: does
> importing "foo" automatically compile "add_blaster", then yes, that
> happens automatically. You can think about that as doing something
> internal that's similar to `System.set`. But that's all implicit. If
> we are in a system like NPM, where "add_blaster" might map
> automatically to "add_blaster.js", we could have:
>
> foo.js:
>
> import go from "add_blaster"
> go(1,2)
>
> add_blaster.js:
>
> export function go(n,m) { return n + m; };
I was using the original code for 'add_blaster', say as you say, it is
in add_blaster.js:
System.set("add_blaster", { go : function(n,m) { return n + m; } });
My understanding that since add_blaster.js uses the runtime API and
not the export, the above code will not work unless I construct a
loader library that first loads and executes add_blaster.js before
foo.js is parsed.
The use case: scripts, like jquery/backbone/others that want to live
in a non-harmony and harmony world, I would expect that they could be
adapted to call the System.set() API, but not use the new syntax
keywords.
I am under the impression that library developers do not want to
provide two different versions of their scripts, just to participate
in es modules, but rather use a runtime check to register as part of
one script that works in es harmony and non-harmony browsers.
Otherwise, it feels like a "2 javascripts" world.
James
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
