Module naming and declarations
claus.reinke at talk21.com
Fri Apr 26 07:20:17 PDT 2013
>> You argue for a two-level system of non-lexical names to support
>> configuration - okay. But why does that imply you have to drop
>> the lexical naming altogether, instead of using a three-level system
>> (from external to internal to lexical names)?
> You don't, it's an orthogonal concern. Note that Sam was *not* arguing
> against the existence of lexical modules.
Good to hear that confirmed.
> But it's not nearly as important as the rest of the core system -- as Sam
> describes, coordination and separate development are the most important
> piece that the module system needs to address. We dropped lexical
> modules mostly in the interest of working out the core and eliminating
> parts that weren't necessary for ES6. Kevin's been urging us to reconsider
> dropping them, and I'm open to that in principle. In practice, however, we
> have to ship ES6.
> But let's keep the question of having lexical *private* modules separate
> from this thread, which is about Andreas's suggestion to have lexical
> modules be the central way to define *public* modules.
There are a couple of problems I see with that: it proposes adding yet
another imperative API to JS where a declarative API would do (adding
modules to the internal registry instead of the local scope); and it misses
the big-rewrite-barrier that is going to accompany ES6 introduction -
modules are the most urgent of ES6 improvements, but do you think
users are going to rewrite their code bases twice just because modules
are going to be delivered in two stages?
You believe you have worked out the core parts that caused you to
postpone lexical modules, and you had a lexical module proposal
before that. What is standing in the way of re-joining those two parts?
More information about the es-discuss