On Jan 26, 2011, at 1:54 PM, Kam Kasravi wrote:

> I assume you mean m.load("la1").

What is m?

Where did "la1" come from?

Confusion.


> 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.

Also, you can't violate JS's run to completion execution model by nesting an 
event loop and blocking on that load until the module, which could be on a far 
away server or even a too-slow-to-block-on disk filesystem, finishes loading.

CommonJS may do that on the server side, assuming fast enough file i/o. It's 
not necessarily a good idea even there (Ryan Dahl has talked about this). On 
the client, it's right out, which is why client-side CommonJS-like module 
systems require a preprocessor or else a callback.


> Is there a module API that allows one to introspect a modules content?

Are you reading the wiki?

/be

> 
> 
> 
> On Jan 26, 2011, at 1:46 PM, Sam Tobin-Hochstadt <sa...@ccs.neu.edu> wrote:
> 
>> On Wed, Jan 26, 2011 at 2:04 PM, James Burke <jrbu...@gmail.com> wrote:
>>> CommonJS Modules 1.1 allows this kind of construct in module code:
>>> 
>>> var a;
>>> if (someCondition) {
>>>   a = require("a1");
>>> } else {
>>>   a = require("a2");
>>> }
>>> 
>>> and the module "a1" is not actually evaluated until execution reaches
>>> the a = require("a1") call.
>>> 
>>> 1) Could something like this work in Simple Modules? If so, what would
>>> be the syntax for it?
>> 
>> You can use module loaders to do exactly this (I believe, based on my
>> understanding of CommonJS).  It would look like:
>> 
>> var ml = ... the desired module loader ...
>> var a;
>> if (someCondition) {
>> a = ml.load("a1");
>> } else {
>> a = ml.load("a2");
>> }
>> 
>> This produces a module instance object, bound to |a|.  It doesn't,
>> however, allow you to import from |a|, since nothing is statically
>> known about what the exports of |a| are.
>> 
>>> 2) What are the design decisions behind only allowing "module" and
>>> "use" at the top level of a module?
>> 
>> Modules are a statically scoped construct, and the implementation and
>> the programmer can both statically tell where variables come from.
>> This prevents modules from being dynamically created, except in the
>> context of module loaders, as seen above.
>> -- 
>> sam th
>> sa...@ccs.neu.edu
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to