On Sat, Apr 2, 2011 at 4:33 PM, David Herman <dher...@mozilla.com> wrote:
>> 2) Set module export value
>> ====================
> That said, we could consider adding functionality to make a module callable,
> to address the use case you describe. Thanks for bringing this up.
Allowing a callable module would go a long way towards bridging the
gap with "settings exports" as that is the primary use of that
feature, although it has been useful for text plugins to set the value
of an AMD module to a text string (see loader plugins section).
> 3a) Is "module" needed inside a module?
>
> Yes. A module declaration declares a binding to a static module. A let/var
> declaration declares a binding to a dynamic value. You only get compile-time
> linking and scoping with static modules.
In that case, I can see the appeal for what Dmitry mentions in his
reply, just reducing it to:
module thing = "some/thing";
Ideally, you could have multiple ones with one module word:
module datePicker = "datePicker",
thing = "some/thing",
Q = "Q";
That would really help with the typing cost seen with traditional
CommonJS modules (require is typed a lot), and better "local
identifier to module name" alignment than what happens in AMD, where
the dependencies and local var names are separate lists :
define(["datePicker", some/thing", "Q"],
function (datePicker, thing, Q({
});
I have gone to aligning the lists to avoid positioning problems, but I
can see how people could find it ugly. Example:
https://github.com/mozilla/f1/blob/master/web/dev/share/panel/index.js
> 3b) Is "import" needed inside a module?
> For many cases, I think that's fine. But .* is an important convenience for
> scripting. Also, FWIW, import is already reserved and has symmetry with
> export, so it seems like a wasted opportunity to fill a natural space in the
> grammar.
Understood. Thanks to you and Brendan for running that one down. I
like the idea of a let {} = someObject; where it only grabs the own
properties of that object at the time of the call, but I can
appreciate if that is difficult to work out and if it skates too close
to "with".
>> 4) How to optimize
>> ====================
>
> I think this is beyond the scope of ECMAScript.next. People are still
> figuring out how to optimize delivery, and web performance patterns are still
> shaking out. ISTM there will be situations where it's more performant to
> combine many modules into one (which can be done with nested module
> declarations) and others where it's more performant to conditionally/lazily
> load modules separately (which can be done with module loaders). I don't
> currently have a clear picture of how we could build syntactic conveniences
> or abstractions for doing this, but at least the pieces are there so
> programmers have the building blocks to start constructing their own tools
> for doing this.
The experience in RequireJS/AMD and in Dojo land is that different
people/projects want different things: sometimes build all modules
into one file, sometimes build some together in one or a couple of
files and have those sets of modules be usable by some other modules
that are loaded separately.
When you say a built file would be possible with nested module
declarations, that makes it sound like those nested modules may not be
usable/visible by other modules that are not loaded as part of that
built file. It would be interesting to explore that more at some
point.
Using string names as the module names in AMD has helped make it
possible to meet the optimization expectations we have seen so far. So
a module that has a 'some/thing' dependency:
define("my/thing", ["some/thing", function (thing){})
when 'some/thing' module is built into the optimized file it has its
string name as the first arg:
define('some/thing', function () {});
I can see this as trickier in Harmony modules, at least for the
examples I have seen, where 'some/thing' needs to be an identifier
like:
module someThing {}
Maybe allow strings instead for the names (I say with blissful syntax
ignorance). Just trying to figure out how to match up string
references to modules in inside a module to a named thing in a built
layer.
>> 5) Loader plugins
>> ====================
>>
>> Some of the AMD loaders support loader plugins[7].
>
> Missing a reference in your bibliography. :)
Sorry, a link would be helpful:
http://requirejs.org/docs/plugins.html
>> 6) Loader API: multiple modules
> Perhaps. We're trying to get the building blocks in place first. We can
> figure out what conveniences are needed on top of that.
>
> BTW, what you're asking for is essentially a concurrent join, which is
> convenient to express in a new library I'm working on called jsTask:
>
> let [m1, m2, m3] = yield join(load("m1.js"), load("m2.js"), load("m3.js"));
I like the ideas behind jsTask, although I would rather not type load that much:
let [m1, m2, m3] = yield load(["m1.js", "m2.js", "m3.js"]);
Array of modules via require([], function (){}) has been useful in
RequireJS, and has a nice parity with the define([], function (){})
dependency list too, although not applicable here. Fair enough if you
want to consider sugar later.
Thanks for your time,
James
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
