ModuleImport

Kevin Smith zenparsing at gmail.com
Fri Jun 27 06:32:03 PDT 2014


>
>
>   - Either we think "real" modules are an improvement, and checking is
> important. Then the model and the syntax should be consistent about
> that. Moreover, checking needs to consistently apply, no matter how a
> module and its components are defined or accessed.
>
>   - Or we come to the conclusion that supporting the legacy singleton
> export model as a primary use case is a mandatory matter. Then we
> should drop attempts of building something in/semi-compatible, and
> limit innovation to making export and import declarative, and
> designing a loader API.
>

Since "real" modules are at the core of the current design, I think the
first option is feasible and equates to simply dropping the "default"
feature, leaving everything else intact.  The second option, on the other
hand, will take us back to the drawing board and I don't see how we can do
that within the ES6 timeline.  We don't want Promises all over again.

So, if we cannot settle on option 1, then I think modules must be deferred
from ES6.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140627/c9ec008c/attachment.html>


More information about the es-discuss mailing list