I understand why callbacks are required for module loaders given they fetch
asynchronously, though it's too bad this isn't more tightly integrated with an
eventing model where events could be published when modules are loaded. I
imagine TC39 has no interest in broaching an event system per se, but IMHO
there would be rapid adoption and tighter integration if module loading could
have associated events like DOMReady etc. A different layer and a different
committee no doubt.
Sent from my iPad
On Jan 26, 2011, at 2:50 PM, David Herman <dher...@mozilla.com> wrote:
> On Jan 26, 2011, at 4:04 PM, Brendan Eich wrote:
>
>> On Jan 26, 2011, at 1:54 PM, Kam Kasravi wrote:
>>
>>> So what is the behavior if you do new m.load("la1").Foo() if you know Foo
>>> is an exported object?
>>
>> Sam addressed that directly ("nothing is statically known"), cited in full
>> below.
>
> Oh, I understand this question better. To clarify a bit further: the module
> loading API returns the first-class module instance objects, rather than
> statically known modules. The code would actually look like this:
>
> ml.load("a1", function(m) {
> // in here, m is just an ordinary variable
> // bound to a first-class object that reflects
> // the contents of the module loaded from "a1"
> ...
> });
>
>>> Is there a module API that allows one to introspect a modules content?
>>
>> Are you reading the wiki?
>
> There are explanations and examples of first-class module instance objects on
> the wiki, but to be fair some of the details are a bit out of date (in
> particular the scoping semantics has changed a bit). Updating the wiki is
> towards the top of my to-do list.
>
> Dave
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
