System.load("http://mylib.com/lib.js";, function(mod) { return
mod.do_stuff(); } )
Since this is async, it might be worthwhile considering more
complex examples (loading multiple libs => nesting or async
libs or promises?).
Here's another example, constructing and installing a module at runtime:
System.set("add_blaster", { go : function(n,m) { return n + m; } })
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);
This dependence on "previous script tag" === earlier group of
loads is easily missed. Could it be made more prominent in the spec?
And could those examples please be added to the modules examples
page? They are helpful starting points for better understanding the
limits and possibilities of the spec.
Certainly, `import *` makes it easier to get name clashes, and we've
designed the system to be resistant to a lot of them. However, it's
great for getting things done quickly, which I hope we all want to
keep supporting. Maybed IDEs for JS will eventually support the same
features that they do for Java, to unfold the * into a bunch of
specific imports, but for hacking something together, convenience and
not repeating lots of names is a big win.
I've found "import *" to be a feature that is great to have and even
better to avoid. Unless there is a static interface file for the imported
module, it weakens module separation. In usage (Haskell) it is great
for standard libs (those functions that just should be there, no matter
where from).
It gets less and less bearable as more and more non standard libs
from module repositories and local installs get added to the mix
(the original author might have an idea what is supposed to come
from where, but most readers won't be so lucky, and even tools
can no longer guess the right definition to choose when newer
versions of dependencies introduce conflicts).
And IDEs can just as well help with inserting the proper qualifiers
or explicit imports when the code is written, so that the code can
be read on a module-by-module basis.
But as you say, coders like to be able to hurt themselves quickly,
so we can leave this to coding standards and linters;-)
Claus
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
