So what I've got is we need static meta data for Module exports. For this
reason "export" keyword is needed.
I was considering if these meta data could be given by the user of Module
(instead of author of Module).
If module file could only be used in ES6 (on need lexical convertion), I
thinking m
Import is currently used by Module. This way of using "import" looks like a
loader feature.
2012/9/26 Russell Leggett
> On Tue, Sep 25, 2012 at 12:08 AM, 程劭非 wrote:
>
>> Thanks, Claus and Alex,
>>
>> I've looked at the Loader but it seems to be async?
>>
>> I know there are many ways to load mu
On Tue, Sep 25, 2012 at 4:27 PM, Claus Reinke wrote:
>> I've looked at the Loader but it seems to be async?
>
> So far, yes, but previous discussions here led to the conclusion
> that making the Loader functionality available for module syntax
> imports would be useful and unproblematic. See, for
On Tue, Sep 25, 2012 at 12:08 AM, 程劭非 wrote:
> Thanks, Claus and Alex,
>
> I've looked at the Loader but it seems to be async?
>
> I know there are many ways to load multiple files together(iframe, XHR,
> script element and datauri for browser host) but what I'm suggesting is to
> make es6 module
I've looked at the Loader but it seems to be async?
So far, yes, but previous discussions here led to the conclusion
that making the Loader functionality available for module syntax
imports would be useful and unproblematic. See, for instance,
the final paragraph of
https://mail.mozilla.org/pip
Thanks, Claus and Alex,
I've looked at the Loader but it seems to be async?
I know there are many ways to load multiple files together(iframe, XHR,
script element and datauri for browser host) but what I'm suggesting is to
make es6 module more friendly to es5 libraries.
I mean currently the es6
I think module loaders would, indeed help, although as you point out,
you're gonna need some sort of transformation step and we don't provide an
AST to work against. You might need something like Traceur's front-end or
esprima to get started on a reliable transform pass. But yeah, doable.
On Mon,
Right. What I'm suggesting isn't that you'll be able to prevent the global
from being augmented, rather that if your goal is to take an *already well
behaved* library and wrap it with modules, that's possible.
Aren't Module Loader Translation hooks meant to help with this?
http://wiki.ecmascr
Hi Shaofei:
Inline:
On Mon, Sep 24, 2012 at 7:22 AM, 程劭非 wrote:
> Thank you for replying, Alex.
>
> Replied inline.
>
> 2012/9/24 Alex Russell :
> > Hi Shaofei:
> >
> > On Sep 22, 2012, at 6:29 PM, 程劭非 wrote:
> >
> >> Hi, everyone,
> >>
> >>
> >> I noticed that current importing grammar will n
Thank you for replying, Alex.
Replied inline.
2012/9/24 Alex Russell :
> Hi Shaofei:
>
> On Sep 22, 2012, at 6:29 PM, 程劭非 wrote:
>
>> Hi, everyone,
>>
>>
>> I noticed that current importing grammar will not work for ES5 files,
>> I mean there is no way to import one or more es5/es3 files as a mo
Hi Shaofei:
On Sep 22, 2012, at 6:29 PM, 程劭非 wrote:
> Hi, everyone,
>
>
> I noticed that current importing grammar will not work for ES5 files,
> I mean there is no way to import one or more es5/es3 files as a module
> and import variables from it.
>
> The problem is:
> 1. There are no "expor
Hi, everyone,
I noticed that current importing grammar will not work for ES5 files,
I mean there is no way to import one or more es5/es3 files as a module
and import variables from it.
The problem is:
1. There are no "export" keywords in a es5/es3 file, no variables are exported.
2. They might b
12 matches
Mail list logo
