My opinion is that CommonJS and AMD work today and will continue to work
into the future so we should optimize for the ideal "looking forward, not
backward" case when adding to the language. Loader will still be
overload-able and since both CommonJS and AMD require a library today it
seems completely reasonable that they will continue to do that and can hook
into es6 through loader extension.
Conclusions:
- Drop default exports
- export function readFile(){}
- import fs from "es6-fs"; // fs.readfile();
- import { readFile } from "es6-fs"; // readFile();
- Done.
- Matthew Robb
On Fri, Jun 27, 2014 at 6:32 AM, Kevin Smith <zenpars...@gmail.com> wrote:
>
>> - 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.
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
