On 11/1/13, 11:32 AM, James Burke wrote:
On Thu, Oct 31, 2013 at 8:32 PM, Jeff Morrison <lbljef...@gmail.com> wrote:
Throwing this out there while I stew on the pros/cons of it (so others can
as well):
I wonder how terrible it would be to have this API define module bodies in
terms of a passed function that, say, accepted and/or returned a module
object?
This would mean allowing `import` and `export` inside a function,
which starts to break down the semantic meaning of what a module "is",
and how to refer to them.
No, that's why I said the function generates an instance of a Module
object imperatively (we're already in imperative definition land with
this API anyway).
No need for `import` or `export`
Any function would be allowed to import or
export. What does that mean? Does a function name now qualify as a
module ID? Why do import statements use string IDs?
If the function wrapping was restricted to only System.* calls to
express dependencies, then it loses out on the cycle benefits of
import and export: it would not be possible to adequately convert a
module that used export/import to a plain function form.
For me, at least as end user, it seems more straightforward to just
allow `module 'id' {}`. It also avoids the ugliness of having strings
of JS inside JS files. I appreciate it may have notable semantic
impacts though.
James
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
