On Sat, Jun 5, 2010 at 2:41 PM, Brendan Eich <[email protected]> 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 _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
