On Wed, Jan 26, 2011 at 5:04 PM, Brendan Eich bren...@mozilla.com wrote:
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
On Jan 27, 2011, at 8:38 AM, Wes Garland wrote:
Kris Kowal's query is interesting: is lazy evaluation worth considering for
Simple Modules?
module M {
export var foo = 42;
export function bar() { return foo; }
alert(hello, world);
}
In the example above,
On Thu, Jan 27, 2011 at 7:27 AM, David Herman dher...@mozilla.com wrote:
We thought for a while about
demand-driven evaluation of modules. There are a couple reasons why I
believe it would be too problematic. First, we'd really like to make the act
of throwing your code into a module as
On the opposite side of the argument, I presume that this means that
modules are evaluated when their transitive dependencies are loaded.
This would imply that the order in which the modules are delivered,
possibly over a network using multiple connections, would determine
the execution
On Thu, Jan 27, 2011 at 9:14 AM, David Herman dher...@mozilla.com wrote:
…but it is required to evaluate them in their declared order,
deterministically.
Would you explain how declaration order is inferred from the contents
of the unordered of files?
It's clear that the order is at least
The easiest way to think about it is to imagine the fully loaded bits of the
whole program as if they were just declared inline in one big file. Then the
total order is manifest -- it's just the order they appear in the program. The
non-deterministic I/O performed by the compiler is just an
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?
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
I assume you mean m.load(la1).
So what is the behavior if you do new m.load(la1).Foo() if you know Foo is an
exported object? Is there a module API that allows one to introspect a modules
content?
On Jan 26, 2011, at 1:46 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
On Wed, Jan 26, 2011
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
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);
}
Correction: you have to use callbacks for dynamic
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
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,
On Jan 26, 2011, at 3:25 PM, Kam Kasravi wrote:
Are you guys following modules 2.0 at all that seems to be a parallel
universe of sorts under co mmonjs? Seems like it should make the strawman in
some form
I'm reading CommonJS when I have time.
This point has been made before:
14 matches
Mail list logo
