On Mon, Apr 15, 2013 at 6:41 AM, Kevin Smith <[email protected]> wrote:
> I think we can all agree that, in principle, program structures which have > scope and define a namespace should be lexically identified and should > nest, unless there is some compelling reason otherwise. > > A module, for any sane definition of the term in the context of > Javascript, has a scope and defines a namespace. Therefore, unless we can > provide some overwhelming argument to the contrary, established design > principles tell us that modules should be lexically identified and should > nest. > > It has been suggested that we can postpone adding lexical modules until > ES7. But to do so would be to postpone conceptual integrity, which is not > an available option. > Hi Kevin, if nothing in the ES6 module system precludes lexical modules, why is postponing lexical modules and conceptual integrity till ES7 not an option? In the same sense, we likewise postponed most of what is needed for classes to have conceptual integrity (as well as literal integrity ;)) till ES7. And the lexical scope cleanups in ES5/strict, in the same sense, didn't have conceptual integrity until the const/let/modules of ES6. We can't get agreement on everything at once. Sometimes, we need experience with the things we do get agreement on to inform the discussions about the remainder. That said, I mostly agree with you on modules. I agree with everything you say here. I say "mostly" only because I believe that modules definitions should be allowed in any lexically nested context. When appearing in a multiply-instantiated lexical context, such as the body of a function, the module definition should itself be multiply instantiable (or generative) as well. This has been true for all defining forms in JavaScript, and it has been a great virtue. However, I don't actually have a coherent end-to-end proposal for making this work (< http://wiki.ecmascript.org/doku.php?id=strawman:simple_module_functions> doesn't work), and it is clear that I could not agreement on one at the present time even if I had one. Moving a consensus forward takes patience, and a sense of which starting steps may productively lead to which paths. ES6 is mostly settled. We should already be focussing most of our unrealized design ambitions on ES7. > > By postponing at-names, for example, we only postpone the usability of > symbols-as-property-names. But by postponing lexical modules, we postpone > the clarity of our design. Indeed, there is nothing in ES6 which requires > more conceptual clarity than modules. Modules should be the mountain > stream of ES6, because with modules we go from a splat of script tags, to a > universe of connected systems. > > Finally, there are actual use cases which require lexical modules. Let's > say that I want to develop a library where each module lives in its own > source file. And let's say that I only want to expose a "main" module, and > hide the rest. Without lexical modules, there is no straightforward build > process capable of encapsulating those internal modules. > > { Kevin } > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
