Composition of Uncoordinated Working Sets of Modules

Kris Kowal kris.kowal at cixar.com
Sat Jun 5 15:18:25 PDT 2010


On Sat, Jun 5, 2010 at 2:41 PM, Brendan Eich <brendan at 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 possible because import m.*
> should not be supported -- that you're arguing against any
> import-everything-that's-exported feature. Right?

Yes, we're in agreement that an early link-error is better than
run-time error.  You are also correct that my argument is that "import
*" should not be supported.  It also true that this is not my primary
objection and it does not poison the design; it is a side-show.

It is also true that this is a value-judgement between the convenience
of the feature when used responsibly by wise and scholarly programmers
within a system of modules designed in coordination, and the value of
protecting programers from the hazard at the cost of that convenience.

CommonJS put this to vote.  There was support on both sides, but on
CommonJS, the feature was sacrificed to get unianimous support.  Only
Tom Robinson called for the "include" function (import *) in the final
show of hands, but cast his +1 without the feature.

http://groups.google.com/group/commonjs/browse_thread/thread/d2dc85a2725992be/4a7fb3943fdbbbbd?lnk=gst&q=modules+include#4a7fb3943fdbbbbd

It is likely that it not possible to get a large enough group of
people either in support of the feature or against the feature to
reach unanimity, and that nobody cares enough either way to block
ratification.  This is far more likely than that there is consensus
either way.

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

Yeah, I've been on both sides of the debate.  I got bitten in the ass
when I was using "from django.models import *", which is naturally a
case of using a module in foreign control (which you note is not
proper usage) but also very compelling because of the royal pain you
mention.  I think it would be good to put this issue to vote.  I think
we're in agreement about the nature of the trade-off and we wouldn't
want to make Buridan donkeys of ourselves.

I also think we should get a show of hands on whether we should try to
decouple "name spaces" (named module clauses per the simple modules
proposal) and "modules" (as linked with a loader), and whether we need
both layers.

Meanwhile, I would still like to see examples of how to compose
working sets of modules with other working sets of modules that were
not designed in coordination.

Kris Kowal


More information about the es-discuss mailing list