yes, we just don't know yet, we have to think about it. there is already a good
discussion happening about the loader shim we plan to provide, etc. look into
the loader repo.
Sent from my iPhone
> On Mar 21, 2015, at 6:14 PM, James Kyle wrote:
>
> >
> > There was then discussion of how to ge
that is correct.
Sent from my iPhone
> On Mar 21, 2015, at 3:52 PM, Kyle Simpson wrote:
>
> Just for posterity sake, since I got tripped up here…
>
> `import .. from this module` did not make it into ES6. It may come in later,
> in that form or some other.
> __
>
> There was then discussion of how to get module metadata, with Dave's initial
> proposal per his slides being this (as Juan shows). However, we eventually
> arrived at the idea of
>
> import { name, url } from this module;
>
Would it make more sense to add additional meta propertie
Just for posterity sake, since I got tripped up here…
`import .. from this module` did not make it into ES6. It may come in later, in
that form or some other.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discus
Thanks, Domenic. Very helpful!
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Was just going through updating @esdiscuss when I noticed nobody really
answered this thread. Which is lame.
The meeting notes at [1] are hard to interpret given that the slides are still
MIA (Dave?). But essentially, import-into-namespace syntax is now `import * as
x from "y"`, replacing the p
// maybe? reference to the loader that actually loaded this module
-Juan
On Wednesday, August 6, 2014 3:31 PM, Axel Rauschmayer wrote:
I haven’t seen any mention of `import * as foo` in the meeting notes, so I’m
assuming that the ES6 module syntax is basically done. Right? Except for the
I haven’t seen any mention of `import * as foo` in the meeting notes, so I’m
assuming that the ES6 module syntax is basically done. Right? Except for the
“import-into-namespace syntax” [1], of course. As an aside, I’m really glad
that `this` won’t be used here (which would have resulted in yet
>
> export let default = 17;
> export default = 17;
> export default = function f() { ... };
> export default = class { ... };
> export function default(...) { ... }
> export class default { ... }
>
>
Interesting, but whether we go the other forms or not, I'm sold on this
si
On Jun 6, 2013, at 11:05 AM, Axel Rauschmayer wrote:
> OK, so you don’t want to replace
>
> import foo from "single_export_module";
>
> with (braceless!)
>
> import default as foo from "single_export_module";
That's correct, I don't want to use `import default`.
Dave
___
On Jun 6, 2013, at 19:42 , David Herman wrote:
> On Jun 5, 2013, at 3:59 PM, Axel Rauschmayer wrote:
>
>> This makes a lot of sense. It would obviate the need for braces, right?
>
> No, at least not for imports. This is only about exports. I'd argue we should
> keep the braces on export { x,
On Jun 5, 2013, at 2:58 PM, Domenic Denicola
wrote:
> From: David Herman [dher...@mozilla.com]
>
>> Moreover, Yehuda has urged me to consider
>>
>> export x = 17;
>>
>> as sugar for
>>
>> export let x = 17;
>
> I'd urge `const` instead of `let`, as `const` discourages the footgun of
>
On Jun 5, 2013, at 3:59 PM, Axel Rauschmayer wrote:
> This makes a lot of sense. It would obviate the need for braces, right?
No, at least not for imports. This is only about exports. I'd argue we should
keep the braces on export { x, y, z } for symmetry with imports.
Dave
___
This makes a lot of sense. It would obviate the need for braces, right?
> Yes, this is actually the direction I've been going in my thinking, based on
> the critique that export default is the only export form that isn't a binding
> form, especially when combined with a named function literal (`
From: David Herman [dher...@mozilla.com]
> Moreover, Yehuda has urged me to consider
>
>export x = 17;
>
> as sugar for
>
>export let x = 17;
I'd urge `const` instead of `let`, as `const` discourages the footgun of
action-at-a-distance mutable `with`/global-like bindings that I keep talk
I really like the way this sounds, just wanted to submit my approval :D
On Wed, Jun 5, 2013 at 12:37 PM, David Herman wrote:
> On Jun 5, 2013, at 11:51 AM, Kevin Smith wrote:
>
> > It occurs to me that this is valid under the current grammar:
> >
> > import { default as foo } from "foo";
>
On Jun 5, 2013, at 11:51 AM, Kevin Smith wrote:
> It occurs to me that this is valid under the current grammar:
>
> import { default as foo } from "foo";
> export { foo as default };
>
> We've discussed using a well-known symbol for the default export, but this
> simple desugaring migh
It occurs to me that this is valid under the current grammar:
import { default as foo } from "foo";
export { foo as default };
We've discussed using a well-known symbol for the default export, but this
simple desugaring might be another option:
import foo as "foo";
// => import {
Sorry - corrections to examples:
import foo from "foo";
// => import { default as foo } from "foo";
export default = expr;
// => let __genident__ = expr; export { __genident__ as default };
module Foo from "foo";
Foo.default();
Thanks,
{ Kevin }
`import foo from "foo";` reads to the quick eye as "import the symbol
named foo from the module named 'foo'" -- but that's not actually what
it means (wrapped curlies be damned!).
I think the syntax would read much less confusingly if we made use of a
`default` keyword to signify better what's h
>
> > Bikeshedding:
>
> Well, here comes a fun thread...
>
>
Bikeshedding *is* fun : )
FWIW, I've implemented a parser for curly-free syntax and it does introduce
some minor parsing difficulties on the export side. If we had lexical
modules, then this:
export module as ...
could be a valid
On Mon, Jun 3, 2013 at 1:55 PM, Juan Ignacio Dopazo
wrote:
> Now that it's been decided that braces are not a form of destructuring and
> the colon replaced with `as`, what's the benefit of using braces? Why not
> this previous proposal?
>
> import foo as foofoo from "foo";
>
> import "bar" as bar
On Jun 3, 2013, at 10:29 AM, Axel Rauschmayer wrote:
> Bikeshedding:
Well, here comes a fun thread...
> Rationale:
> – Reducing the grawlix factor.
> – Making non-default imports more convenient – which I assume will happen
> more often(?)
That's what this comes down to: do you expect the com
On Jun 3, 2013, at 1:55 PM, Juan Ignacio Dopazo wrote:
> Now that it's been decided that braces are not a form of destructuring and
> the colon replaced with `as`, what's the benefit of using braces? Why not
> this previous proposal?
>
> import foo as foofoo from "foo";
>
> import "bar" as ba
Now that it's been decided that braces are not a form of destructuring and
the colon replaced with `as`, what's the benefit of using braces? Why not
this previous proposal?
import foo as foofoo from "foo";
import "bar" as bar;
Juan
___
es-discuss maili
if
```
function x() {}
export default x;
```
works thought, that ain't any different from returning function expression
where you cannot reuse that function if not inside the function itself.
It does not look like a big lost but more similar to expression logic we
are use to with JS ... or, is i
+1
as soon as the syntax is slightly different from NPM/AMD makes sense to
have less ambiguity and a better definition.
export default looks good here too
On Mon, Jun 3, 2013 at 12:57 PM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:
> I really dislike `export =`. It looks like it sho
> `export default` is perfect IMO. It also conceptually fits better with how
> default exports work. (I.e., they're *default* exports, they're not the
> entirety of the exports. They don't overwrite the module instance object,
> in the fashion that `module.exports =` does.)
>
>
A potential problem
On Mon, Jun 3, 2013 at 3:57 PM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:
> I really dislike `export =`. It looks like it should be creating a global
> variable named `export`.
>
> `export default` is perfect IMO. It also conceptually fits better with how
> default exports work. (I.e.
We may be able to have both: convenient default imports and convenient
non-default imports, if we bring back `export =` (which, IIRC, has been
proposed a while ago) and introduce `import =` as an analog. Example:
module "jquery" {
export = {
...
};
}
import $ = "jquery";
Not co
I was corresponding with Axel about what's possible without ambiguity,
and he pushed for brace elimination noting that 'default' is a reserved
word. This led to me remembering the export = ... form, more concise
than export default ... -- not that "more concise" must win, but it
seems worth a b
I really dislike `export =`. It looks like it should be creating a global
variable named `export`.
`export default` is perfect IMO. It also conceptually fits better with how
default exports work. (I.e., they're *default* exports, they're not the
entirety of the exports. They don't overwrite the
On Jun 3, 2013, at 20:41 , Rick Waldron wrote:
> On Mon, Jun 3, 2013 at 2:40 PM, Axel Rauschmayer wrote:
>> On Mon, Jun 3, 2013 at 1:29 PM, Axel Rauschmayer wrote:
>> Bikeshedding: I generally like the module syntax, but I’d always omit the
>> braces and use `import defau
On Mon, Jun 3, 2013 at 1:29 PM, Axel Rauschmayer wrote:
> Bikeshedding: I generally like the module syntax, but I’d always omit the
> braces and use `import default` for importing the default export of a
> module.
>
>From the wiki:
module "foo" {
export default
On Mon, Jun 3, 2013 at 2:40 PM, Axel Rauschmayer wrote:
> On Mon, Jun 3, 2013 at 1:29 PM, Axel Rauschmayer wrote:
>
>> Bikeshedding: I generally like the module syntax, but I’d always omit the
>> braces and use `import default` for importing the default export of a
>>
> On Mon, Jun 3, 2013 at 1:29 PM, Axel Rauschmayer wrote:
> Bikeshedding: I generally like the module syntax, but I’d always omit the
> braces and use `import default` for importing the default export of a module.
>
> From the wiki:
>
> module "foo"
Bikeshedding: I generally like the module syntax, but I’d always omit the
braces and use `import default` for importing the default export of a module.
Rationale:
– Reducing the grawlix factor.
– Making non-default imports more convenient – which I assume will happen more
often(?)
--
Dr. Axel
Apologies if the "import module" syntax has already been agreed upon (in
which case I'll be happy to use whatever it is), but in converting over
some code to ES6 modules, I've found myself dissatisfied with both "variant
A" and "variant B".
I've cr
38 matches
Mail list logo
