On Jan 29, 2010, at 6:50 PM, Allen Wirfs-Brock wrote:
David and Sam, well done!
Lots of nits to pick and ideas to discuss but this makes it very
clear how a simple "static" (or 2nd class) module system could
nicely integrate into ECMAScript.
I wanted to mention that "second class" is not a
I'll add an example demonstrating modules with shared state; if you want to
make a point about the consequences of this, I'm happy to discuss.
WRT isolation, Sam and I have some thoughts about a largely orthogonal proposal
for providing isolation without needing to impose restrictions on the sem
On Fri, Jan 29, 2010 at 5:13 PM, David Herman wrote:
> We had a good discussion about modules at this week's meeting, and Sam
> Tobin-Hochstadt and I have worked out a strawman for a simple module system.
> I've posted a first draft to the wiki:
>
> http://wiki.ecmascript.org/doku.php?id=stra
There is quite a bit of literature on "2nd class" module systems, but most of
it is from a period before first class modules became the primary modularity
research interest. I'll see if I can dig up some references to papers that may
be helpful.
One of the points that I recall is the importan
On Sat, Jan 30, 2010 at 9:46 AM, Dave Herman wrote:
> I'll add an example demonstrating modules with shared state; if you want to
> make a point about the consequences of this, I'm happy to discuss.
Ok thanks. I assume your longer description notes what the state would
be as seen from two indepen
Allen:
I agree with the assessment of entangling configuration management and module
management.
Both module specifications have this issue, although Ihab's package proposal
attempts to separate the two.
In the community, the commonjs syntax is 'require("./compiler/Lexer");' which
implicitly s
> There is quite a bit of literature on “2nd class” module systems, but
> most of it is from a period before first class modules became the
> primary modularity research interest. I’ll see if I can dig up some
> references to papers that may be helpful.
That would be great. I'll be glad to include
Hi Andy,
> So, as Brendan described, they're not first class because you want to
> analyze dependencies statically?
A number of reasons:
- the dependency graph is statically computable
- first-class modules duplicate existing expressiveness of functions and objects
- exposing more information to
> Ok thanks. I assume your longer description notes what the state
> would be as seen from two independent usages of module Counter?
I may not have made this clear enough in the strawman. A module is evaluated
only once, so two independent usages will share state.
Now, this is "per context" -- t
9 matches
Mail list logo
