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 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 second-class modules is the ability to manage
static
bindings; for example, import m.*; is statically manageable. Allen
has made some good points about how second-class modules are a good
fit for the programmer's mental model of statically delineated
portions of code. At any rate, cyclic dependencies are not the
central point.
As far as I can tell, Simple Modules only changes the composition
hazard introduced by "imoprt m.*" from a run-time hazard to a
link-time hazard.
In your example, certainly the earlier error is a benefit of our
proposal.
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 possible because
import m.* should not be supported -- that you're arguing against any
import-everything-that's-exported feature. Right?
Either Alice is at fault for using "import m.*",
Charlie is at fault for altering her API, or neither Alice and Charlie
are at fault because they were merely and earnestly using the features
of the underlying system, in which case the system is at fault. Alice
should be able to trust the features of her module system. Charlie
should be able to *augment* her API without breaking her dependents.
The only reason import m.* is in the proposal is that when one is
using modules in one's *own* (definitely including the single-author
case, but also the single-curator and same-origin-hosted case) larger
program, where the hazard of new names can be controlled by testing
and auditing, then lack of import m.* is a royal pain. This is
especially true during rapid prototyping.
If * imports were considered too dangerous because they might be
abused at scale and across administrative boundaries, then they could
be dropped. This is a sideshow -- it doesn't get at the essential
issue of second- vs. first-class module system, or other seeming bones
of contention.
But I don't think there's a consensus to drop * imports. Lots of
things in JS can be abused, but are not so hazardous they should be
removed. True,'with' is gone in ES5 strict, eval is tamed somewhat.
Perhaps there's a case for a future stricter strict mode forbidding *
imports, but it's not obviously worth the added modal complexity.
But the really key benefit is this:
module M {
export x = 7;
}
module N {
M.y + 3; // an error - just like an unbound variable in ES5 strict
}
This feature does not preclude the omission of the import * syntax
variant.
Right -- no one is saying * imports must be part of the system to keep
other aspects of the design working. And singling out * imports does
not argue against the whole design.
This can be an early error because we statically know a lot about
modules. This is good for programmers, because it supports early
errors, and also good for compiler writers, since it supports
optimization.
I agree. I do not think that any of my objections preclude statically
linking name spaces.
Ok, then it seems you did agree earlier too, that an early error is
better than a runtime error. Whew!
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
