On Sun, Jun 6, 2010 at 2:00 PM, Kris Kowal kris.ko...@cixar.com wrote:
Supposing that aQuery and bQuery are implemented by independent
uncoordinated authors.
aQuery.js
module $ {
}
bQuery.js
module $ {
}
If my interpretation is correct, these cannot be combined in a
On Mon, Jun 7, 2010 at 8:37 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
On Sun, Jun 6, 2010 at 2:00 PM, Kris Kowal kris.ko...@cixar.com wrote:
...
Most of this is good clarification, particularly that load
interacts with the exports of the foreign script's implied,
anonymous module scope.
On Mon, Jun 7, 2010 at 10:35, Kris Kowal kris.ko...@cixar.com wrote:
Another thing that Ihab clarified which merits a full
section on the wiki is the dynamic scoping of lexical module
names.
This is a common misconception. Simple modules is using static lexical
scoping, not dynamic scoping.
It would be
good for this to be expressed in one of the examples, and
for it to be clarified in the description of semantics that
every script is also an anonymous module from which the
exports are only accessible through the lexical scope
shadowing (I assume) and by being bound to a module
On Mon, Jun 7, 2010 at 12:10 PM, Erik Arvidsson
erik.arvids...@gmail.com wrote:
On Mon, Jun 7, 2010 at 10:35, Kris Kowal kris.ko...@cixar.com wrote:
Another thing that Ihab clarified which merits a full
section on the wiki is the dynamic scoping of lexical module
names.
This is a common
Supposing that aQuery and bQuery are implemented by independent
uncoordinated authors.
aQuery.js
module $ {
}
bQuery.js
module $ {
}
If my interpretation is correct, these cannot be combined in a single
Application.
script type=harmony src=aQuery.js/script
script
On Fri, Jun 4, 2010 at 9:48 PM, Kris Kowal kris.ko...@cixar.com wrote:
On Fri, Jun 4, 2010 at 5:17 PM, David Herman dher...@mozilla.com wrote:
By keeping modules second class, we get a number of benefits, not
just handling cyclic dependencies. (In fact, cyclic dependencies can
be handled
On Sat, Jun 5, 2010 at 3:40 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
On Fri, Jun 4, 2010 at 9:48 PM, Kris Kowal kris.ko...@cixar.com wrote:
On Fri, Jun 4, 2010 at 5:17 PM, David Herman dher...@mozilla.com wrote:
By keeping modules second class, we get a number of benefits, not
just
On Jun 5, 2010, at 2:17 PM, Kris Kowal wrote:
On Sat, Jun 5, 2010 at 3:40 AM, Sam Tobin-Hochstadt
sa...@ccs.neu.edu wrote:
On Fri, Jun 4, 2010 at 9:48 PM, Kris Kowal kris.ko...@cixar.com
wrote:
On Fri, Jun 4, 2010 at 5:17 PM, David Herman dher...@mozilla.com
wrote:
By keeping modules
On Sat, Jun 5, 2010 at 2:41 PM, Brendan Eich bren...@mozilla.com wrote:
I strongly disagree.
Whoa -- I don't see how anyone can disagree that early error is better than
a runtime error, if there is an error case at all. It seems to me you're
instead arguing that no such error should be
Simple Modules are, in their present state, one step forward and two
steps back from the previous generation of proposals. With this
email, I intend to isolate these steps and propose a way to meet one
or two steps forward.
The one step forward comes from handling cyclic dependencies
elegantly.
Hi Kris,
Thanks for your thoughts; I'll keep reading but I do want to respond to a
couple points that I don't think are quite accurate.
The one step forward comes from handling cyclic dependencies
elegantly. If I am correct, this is the feature we gain from second
classness and from not
On Fri, Jun 4, 2010 at 5:17 PM, David Herman dher...@mozilla.com wrote:
By keeping modules second class, we get a number of benefits, not
just handling cyclic dependencies. (In fact, cyclic dependencies can
be handled nicely in a first-class module system as well.) One of
the benefits of
13 matches
Mail list logo
