Re: Duplicate property names (was Re: @@new)
On Thu 19 Jun 2014 18:02, Mark S. Miller erig...@google.com writes:
Yes. For both strict and sloppy, for both static/literal and
dynamic/computed, duplicate property names/symbols in object literals
are no longer an error. Instead, in left-to-right order, each cause the
equivalent of a [[DefineOwnProperty]] on the new object, so that
rightward definitions silently overwrite conflicting leftward
definitions. This should not result in any change to sloppy literals. It
just makes strict literals, regarding this issue alone, act like sloppy
literals. (Once we have a way to express that a property is to be
initialized to a non-configurable state, we'll need to revisit this. But
that's after ES6.)
There is one change:
({ foo: 3, get foo() { return 4 } })
This is not allowed with current sloppy mode. Are you proposing that it
be allowed, given that this situation may arise with computed property
names:
({ ['foo']: 3, get foo() { return 4 } })
or
({ foo: 3, get ['foo']() { return 4 } })
Andy
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ModuleImport
ES6 favors the single/default export style, and gives the sweetest syntax
to importing the default. Importing named exports can and even should be
slightly less concise.
It seems like ES6 favors single import (`import singleThing from module`)
but prefers multiple export (`export var a = 5;`), with single/default
export being a special case of named/multiple export. In the spec[1] there
are 5 ways to export named things, but only one way to export a default
value. The focus in the spec is therefore on multiple export, while single
export is a special case using a keyword to differentiate itself. This
means that a module which exports only a single (named) thing is not a
single-export module, and cannot be imported using the single-import syntax:
```js
//moduleA.js
export class A{
//...
}
//app.js
import A from moduleA; //wont work, even though moduleA only has a single
export
```
This will likely lead to confusion, since the ES6 module system does not
actually favor single export modules, but default export modules. If the
ES6 module system is trying to push developers towards single exporting
modules, then the syntax for export should prefer single export, without
requiring a keyword for it to actually be a single export module. Multiple
export should be the special case, requiring a keyword or new syntax, and
throwing if a module exports multiple times without the extra keyword.
Unfortunately I don't have any suggestions for how this syntax could work
without deviating very far from the current spec. It seems easier to get
the spec to favor multiple export (which, to me, it looks like it was
originally designed to favor). I don't have any preference either way, I
just want it to favor one, both on the export and import side.
Marius Gundersen
[1](http://people.mozilla.org/~jorendorff/es6-draft.html#sec-exports)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Range generator
Hi, Is there plans to add a range generator to the standard library ? It would be especially useful with array comprehension, when initializing arrays : this._year = [ new Month(n) for n of Number.range(0, 12) ] -- Maël Nison (arcanis https://twitter.com/arcanis) Frontend Developer @ Sketchfab ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
TC39 vs the community
Hi,
I'm not quite sure what this is all about, so forking in hope for
clarifications.
I'm sorry to send a message that will probably be read as noise by a lot
of people, but I'm also tired of some of these pointless and
unconstructive, if not destructive, fights among people (in here, on
Twitter or elsewhere).
I hope to have a conversation to start the end of the alleged
unharmonious relationship between TC39 and JS developers.
Domenic, your email suggests a fairly strong dichotomy between TC39
and the community. As far as I'm concerned, to begin with, I don't see
anything that is called the community in JavaScript. I join Axel's
point of view. I see lots of communities with different backgrounds and
interests, especially among the JS devs.
I personnally don't feel associated with the community you describe. I
encourage you to either speak only for yourself or provide a more
specific description of whose point of view you're referring to
(preferably without a definite article).
Le 19/06/2014 21:13, Domenic Denicola a écrit :
Unfortunately, that's not the world we live in, and instead TC39 is designing a
module system based on their own priorities. (Static checking of multi-export
names, mutable bindings, etc.)
If I knew nothing about how ES standardization works, I'd be thinking
who the fuck are these TC39 people who decide features based on their
own agenda against the interest/experience of the developers? Who do
they think they are anyway?
Can you develop these particular accusations?
Why would TC39 have priorities that don't align with the needs of
developers? especially on modules which are clearly one of the most
awaited feature as far as developers are concerned?
I'm not quite sure I understand the dichotomy and the alleged TC39
priorities that would be that far off from what JS devs otherwse need,
so please get it off your chest so we can all move on.
They've (wisely) decided to add affordances for the community's use cases, such as layering default
exports on top of the multi-export model. As well as Dave's proposal in this thread to de-grossify
usage of modules like fs. By doing so, they increase their chances of the module system
being good enough for the community, so that the path of least resistance will be to
adopt it, despite it not being designed for them primarily. It's still an open question whether
this will be enough to win over the community from their existing tools, but with Dave's suggestion
I think it has a better-than-even chance.
The transitional era will be a particularly vulnerable time for TC39's module design, however: as
long as people are using transpilers, there's an opportunity for a particularly well-crafted,
documented, and supported transpiler to give alternate semantics grounded in the community's
preferred model, and win over enough of an audience to bleed the life out of TC39's modules. We
already see signs of community interest in such ES6+ transpilers, as Angular
illustrates. Even a transpiler that maintains a subset of ES6 syntax would work: if it supported
only `export default x`, and then gave `import { x } from y` destructuring semantics
instead of named-binding-import semantics, that would do the trick. Interesting times.
Whatever TC39 settles in and is eventually part of the standard will
inevitably have tooling associated to it. Maybe not by the community
(whoever that is), but I'm fairly certain TypeScript will adopt it for
instance. I'm fairly sure IDEs will all eventually have syntactic or
intelligent support of the official standard modules (which is less
clear for whatever-transpiler-modules).
Some people who aren't part of the community will write code in ES6
modules. Whatever they end up being, I'll probably be on that end pretty
much for the same reason I choose to not write coffeescript (because
AFAIC my own taste in code has less worth than other's ability to
understand the code I write).
Whatever they end up looking and behaving, ES6 modules will happen with
the community or without it.
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ModuleImport
Reading Marius' email, I realised what I find confusing in the newly
proposed syntax that uses `*' to import the default export.
The `*' symbol universally represents a glob of everything, but when
used to import from a module that has multiple exports, you won't get
everything, you will get either the single default export (if there is
one) or nothing.
```js
// letters.js
export var a = 1;
export var b = 2;
// main.js
import {a, b} from letters; // ok
import * as letters from letters; // not what you think
```
Note that `{ * }' would be even more confusing.
Would `default' be a clearer keyword for import, so import and export
logically match?
```js
import default as Dict from dict;
```
As a final note, and at the risk of erring in the world of speculation
that Brendan fears, are we just sleepwalking towards pushing people to
work around the whole debate with the universal:
```js
// letters.js
export var a = 1;
export var b = 2;
export default {a: a, b: b};
// main.js
import {a, b} from letters; // ok
import * as letters from letters; // ok
```
Sorry to add more data to this already loaded thread. I guess it shows
how much people care about finding the best, most intuitive solution
to this whole issue.
On 20 Jun 2014 09:49, Marius Gundersen gunder...@gmail.com wrote:
ES6 favors the single/default export style, and gives the sweetest syntax
to importing the default. Importing named exports can and even should be
slightly less concise.
It seems like ES6 favors single import (`import singleThing from module`)
but prefers multiple export (`export var a = 5;`), with single/default export
being a special case of named/multiple export. In the spec[1] there are 5
ways to export named things, but only one way to export a default value. The
focus in the spec is therefore on multiple export, while single export is a
special case using a keyword to differentiate itself. This means that a
module which exports only a single (named) thing is not a single-export
module, and cannot be imported using the single-import syntax:
```js
//moduleA.js
export class A{
//...
}
//app.js
import A from moduleA; //wont work, even though moduleA only has a single
export
```
This will likely lead to confusion, since the ES6 module system does not
actually favor single export modules, but default export modules. If the ES6
module system is trying to push developers towards single exporting modules,
then the syntax for export should prefer single export, without requiring a
keyword for it to actually be a single export module. Multiple export should
be the special case, requiring a keyword or new syntax, and throwing if a
module exports multiple times without the extra keyword.
Unfortunately I don't have any suggestions for how this syntax could work
without deviating very far from the current spec. It seems easier to get the
spec to favor multiple export (which, to me, it looks like it was originally
designed to favor). I don't have any preference either way, I just want it to
favor one, both on the export and import side.
Marius Gundersen
[1](http://people.mozilla.org/~jorendorff/es6-draft.html#sec-exports)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
--
Visit theguardian.com. On your mobile and tablet, download the Guardian
iPhone and Android apps theguardian.com/guardianapp and our tablet editions
theguardian.com/editions. Save up to 57% by subscribing to the Guardian
and Observer - choose the papers you want and get full digital access.
Visit subscribe.theguardian.com
This e-mail and all attachments are confidential and may also be
privileged. If you are not the named recipient, please notify the sender
and delete the e-mail and all attachments immediately. Do not disclose the
contents to another person. You may not use the information for any
purpose, or store, or copy, it in any way. Guardian News Media Limited
is not liable for any computer viruses or other material transmitted with
or as part of this e-mail. You should employ virus checking software.
Guardian News Media Limited is a member of Guardian Media Group plc.
Registered
Office: PO Box 68164, Kings Place, 90 York Way, London, N1P 2AP. Registered
in England Number 908396
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ModuleImport
On Jun 20, 2014, at 11:36 , Sébastien Cevey seb.ce...@guardian.co.uk wrote: Reading Marius' email, I realised what I find confusing in the newly proposed syntax that uses `*' to import the default export. The `*' symbol universally represents a glob of everything, but when used to import from a module that has multiple exports, you won't get everything, you will get either the single default export (if there is one) or nothing. What gives you that impression? Quoting David’s original email: ```js import * as fs from fs; // importing the named exports as an object import Dict from dict; // importing a default export, same as ever ``` As a final note, and at the risk of erring in the world of speculation that Brendan fears, are we just sleepwalking towards pushing people to work around the whole debate with the universal: “are we just sleepwalking” – what are you implying? Axel -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ModuleImport
On 20 June 2014 11:39, Axel Rauschmayer a...@rauschma.de wrote: The `*' symbol universally represents a glob of everything, but when used to import from a module that has multiple exports, you won't get everything, you will get either the single default export (if there is one) or nothing. What gives you that impression? Quoting David’s original email: ```js import * as fs from fs; // importing the named exports as an object import Dict from dict; // importing a default export, same as ever ``` Ah my bad, I must have got confused somewhere along the thread. That makes perfect sense to me too, ignore what I said. As a final note, and at the risk of erring in the world of speculation that Brendan fears, are we just sleepwalking towards pushing people to work around the whole debate with the universal: “are we just sleepwalking” – what are you implying? Given what you highlighted above, there would be a native syntax to give people the different cases they might need, so they would have no reason to do other silly workarounds. Thanks for the clarification, and apologies for my misunderstanding! -- Sébastien Cevey Software Developer -- -- Visit theguardian.com. On your mobile and tablet, download the Guardian iPhone and Android apps theguardian.com/guardianapp and our tablet editions theguardian.com/editions. Save up to 57% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit subscribe.theguardian.com This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News Media Limited is a member of Guardian Media Group plc. Registered Office: PO Box 68164, Kings Place, 90 York Way, London, N1P 2AP. Registered in England Number 908396 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Range generator
Btw, I used the wrong syntax in my precedent mail. It should be : [ for (n of Number.range(0, 12)) new Month(n) ] On 20 June 2014 11:24, Maël Nison nison.m...@gmail.com wrote: Hi, Is there plans to add a range generator to the standard library ? It would be especially useful with array comprehension, when initializing arrays : this._year = [ new Month(n) for n of Number.range(0, 12) ] -- Maël Nison (arcanis https://twitter.com/arcanis) Frontend Developer @ Sketchfab -- Maël Nison (arcanis https://twitter.com/arcanis) Frontend Developer @ Sketchfab ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Duplicate property names (was Re: @@new)
Yes, good catch. This is a change, and it is now allowed.
On Fri, Jun 20, 2014 at 1:48 AM, Andy Wingo wi...@igalia.com wrote:
On Thu 19 Jun 2014 18:02, Mark S. Miller erig...@google.com writes:
Yes. For both strict and sloppy, for both static/literal and
dynamic/computed, duplicate property names/symbols in object literals
are no longer an error. Instead, in left-to-right order, each cause the
equivalent of a [[DefineOwnProperty]] on the new object, so that
rightward definitions silently overwrite conflicting leftward
definitions. This should not result in any change to sloppy literals. It
just makes strict literals, regarding this issue alone, act like sloppy
literals. (Once we have a way to express that a property is to be
initialized to a non-configurable state, we'll need to revisit this. But
that's after ES6.)
There is one change:
({ foo: 3, get foo() { return 4 } })
This is not allowed with current sloppy mode. Are you proposing that it
be allowed, given that this situation may arise with computed property
names:
({ ['foo']: 3, get foo() { return 4 } })
or
({ foo: 3, get ['foo']() { return 4 } })
Andy
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: TC39 vs the community
Can you develop these particular accusations? Why would TC39 have priorities that don't align with the needs of developers? especially on modules which are clearly one of the most awaited feature as far as developers are concerned? TC39 has a lot of constituents who use their experience with other languages to develop the shape of features, instead of building on community-developed solutions to the problems the community sees as worth solving. In modules this is particularly apparent. If you want a qualifier for community, try ES5-module using community. I wouldn't call these accusations, and in general I don't appreciate the uncharitable (perhaps even accusatory) tone of your message. Experience from other languages is valuable in evolving a language---of course! It would be silly to think otherwise. And often these working modes are not in conflict at all, allowing us to solve problems the community has run into by drawing upon our experience with other languages. But there is, especially in this case, a real conflict between the guidance from other languages and the guidance from the ES5-module using community's experience. Whatever they end up looking and behaving, ES6 modules will happen with the community or without it. They may happen, in that engines may indeed implement the syntax once it settles, and browsers may indeed implement a loader once it's designed and specced. But whether they will be adopted by, say, Node.js (by supplying their own loader implementation), or the 80K packages on npm, or by the developers who are currently using AMD, or the developers who are currently just happy with script tags, is another question. Any claims otherwise are tendentious speculation, to borrow a phrase. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: TC39 vs the community
On Fri, Jun 20, 2014 at 6:42 AM, Domenic Denicola dome...@domenicdenicola.com wrote: Can you develop these particular accusations? Why would TC39 have priorities that don't align with the needs of developers? especially on modules which are clearly one of the most awaited feature as far as developers are concerned? TC39 has a lot of constituents who use their experience with other languages to develop the shape of features, instead of building on community-developed solutions to the problems the community sees as worth solving. In modules this is particularly apparent. If you want a qualifier for community, try ES5-module using community. The ES5-module using community tried, valiantly, to reach a compromise module solution. They were not successful. Thus ES6 cannot build on their solution. Their experience did however have a huge impact on the ES6 module design. I wouldn't call these accusations, and in general I don't appreciate the uncharitable (perhaps even accusatory) tone of your message. Experience from other languages is valuable in evolving a language---of course! It would be silly to think otherwise. And often these working modes are not in conflict at all, allowing us to solve problems the community has run into by drawing upon our experience with other languages. But there is, especially in this case, a real conflict between the guidance from other languages and the guidance from the ES5-module using community's experience. I started out with a similar opinion. Then I wrote some ES6 code. What we need now is experience from using ES6-modules. We have plenty of decent implementations. We've built nodejs and browser applications based on ES6 modules. That experience shows that the ES6 solution is modestly superior to any ES5 solution. Moreover the ES6 solution interoperates with the main ES5 solutions. Are there projects which attempted to use ES6 modules but where unable to succeed because of technical barriers? Whatever they end up looking and behaving, ES6 modules will happen with the community or without it. They may happen, in that engines may indeed implement the syntax once it settles, and browsers may indeed implement a loader once it's designed and specced. But whether they will be adopted by, say, Node.js (by supplying their own loader implementation), or the 80K packages on npm, or by the developers who are currently using AMD, or the developers who are currently just happy with script tags, is another question. Any claims otherwise are tendentious speculation, to borrow a phrase. Implementors and proponents of legacy systems always fight for their point of view. It's natural and valuable input. But at this point we are speculating about tendencies of developers, not arguing about technical feasibility. Some node developers will never switch; some devs will always use script tags; some business apps will be written in COBOL. It's ok. jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ModuleImport
On Thu, Jun 19, 2014 at 8:48 PM, Brendan Eich bren...@mozilla.org wrote: Domenic Denicola wrote: The transitional era will be a particularly vulnerable time for TC39's module design, however: as long as people are using transpilers, there's an opportunity for a particularly well-crafted, documented, and supported transpiler to give alternate semantics grounded in the community's preferred model, and win over enough of an audience to bleed the life out of TC39's modules. You're doing a disservice to everyone here by implying that such a transpiler could trump native modules as implemented per the normative ES6 spec in Chakra, JSC, SpiderMonkey, and V8. Idle speculations are not even worth betting on, but filling es-discuss with tendentious idle speculations is worse. Cut it out. Domenic may have erred by conflating many different constituencies into a monolithic, definite version of “the community”, but I don’t think his characterization of a “transitional era” or the risks therein are tendentious. Some people on es-discuss (including, at times, Domenic) seem to assume that Node.js developers will embrace ES6 part and parcel, when the feedback I receive on a daily basis is very different. (As I’m primarily a Node developer, I can’t speak to the concerns of other groups within the broader JS community, but I do think the feedback coming from e.g. James Burke is valuable here.) I bring up these concerns not because I agree with them, but because I feel awkward about the disconnect between the message I see coming out of TC39 and the response from my friends and peers. I’m also concerned about schisms happening within the Node community, especially if the team developing the platform and the broader developer community find themselves at odds when it comes to module systems. That said, there are two overarching themes that tend to come up in discussions among Node developers when the ES6 module system is discussed: 1. Node’s module system is frozen. There has long been an ideology within Node that there will be a point at which it is “finished”, and at that point the platform / kernel will have a frozen API and all of the innovation around Node will happen in the module ecosystem. The forcing function for this is Node’s stability index http://nodejs.org/api/documentation.html#documentation_stability_index, which is a ratchet much like the ES7 design process, where once a piece of the platform attains a higher level of stability, it can’t move to a lower one. The module system is one of the few pieces of Node that has the highest, locked level of stability. This is in part because it’s the piece that connects Node to npm and the module ecosystem. It has also long been the locus of long and difficult debates https://github.com/joyent/node/issues/6960, and getting the module system to the locked state was a key move in fostering the active growth of the Node ecosystem, even though (as that thread shows) it clearly still has unresolved issues. I can see a future in which ES6 modules are a part of V8 and therefore included in Node, and also where somebody builds a module loader that maps ES6 modules onto the Node module loader. Projects like jspm http://jspm.io/ are interesting in this regard, but this is all being done in the context of a “finished” module system, so there’s a deep skepticism (sometimes bordering on dismissiveness) on the part of Node’s core development team that moving Node to using ES6 modules by default is a thing that could even happen. 2. Node’s modules are good enough for all use cases. This is obviously a subjective statement that’s burdened with a large load of implicit assumptions, but it’s one I see a lot, especially from the community built up around browserify. Node’s core APIs tend to use multi-export because they’re themed grab bags (fs, util, os, etc), but the community has converged on single-export / single-purpose modules as the dominant convention for library development. Because CommonJS modules are just a protocol built atop plain JS objects, Node’s module system is easily flexible enough to support both styles of export, and both are entrenched. Any new proposal that ditches or deprecates either of these styles is therefore nearly guaranteed to cause dismay, which is (I believe) what happened when the notes from the module side discussion from the last face to face started circulating. It also shows how high the bar is set when it comes to the Node community switching module systems. There’s little question in my mind that browser-first developers who aren’t heavily invested in AMD will move en masse to whatever ends up being in ES6 (and I believe that this comprises a majority of working JavaScript developers). I do believe that unless the path from Node to ES6 modules is painless, and unless the Node community sees clear value in making the switch, they’re just not going to bother. Maybe this is fine! Transpilers exist, and browserify isn’t going
Re: TC39 vs the community
I'll make this point as concisely as possible, since this conversation is quite given to noise: While others may disagree, I feel the source of contention/disunity on modules is more fundamental than syntax or who's (not) listening to who. Specifically, ES6 modules are far less immune to platform nuances than other features, like, say, fat-arrows. That is, the merits of fat-arrows are basically the same regardless of what platform you're on... but that isn't (as) true of modules. While there's certainly overlap in what Node vs. Browser vs. PhoneGap (etc.) devs want out of a module loader, there are necessarily divergences as well. I say this hesitantly and with great respect for TC39 and its members... but I have a hard time imagining a unified voice emerging on *anything* that's situated this close to individual, disparate platform needs. On Fri, Jun 20, 2014 at 11:39 AM, John Barton johnjbar...@google.com wrote: On Fri, Jun 20, 2014 at 6:42 AM, Domenic Denicola dome...@domenicdenicola.com wrote: Can you develop these particular accusations? Why would TC39 have priorities that don't align with the needs of developers? especially on modules which are clearly one of the most awaited feature as far as developers are concerned? TC39 has a lot of constituents who use their experience with other languages to develop the shape of features, instead of building on community-developed solutions to the problems the community sees as worth solving. In modules this is particularly apparent. If you want a qualifier for community, try ES5-module using community. The ES5-module using community tried, valiantly, to reach a compromise module solution. They were not successful. Thus ES6 cannot build on their solution. Their experience did however have a huge impact on the ES6 module design. I wouldn't call these accusations, and in general I don't appreciate the uncharitable (perhaps even accusatory) tone of your message. Experience from other languages is valuable in evolving a language---of course! It would be silly to think otherwise. And often these working modes are not in conflict at all, allowing us to solve problems the community has run into by drawing upon our experience with other languages. But there is, especially in this case, a real conflict between the guidance from other languages and the guidance from the ES5-module using community's experience. I started out with a similar opinion. Then I wrote some ES6 code. What we need now is experience from using ES6-modules. We have plenty of decent implementations. We've built nodejs and browser applications based on ES6 modules. That experience shows that the ES6 solution is modestly superior to any ES5 solution. Moreover the ES6 solution interoperates with the main ES5 solutions. Are there projects which attempted to use ES6 modules but where unable to succeed because of technical barriers? Whatever they end up looking and behaving, ES6 modules will happen with the community or without it. They may happen, in that engines may indeed implement the syntax once it settles, and browsers may indeed implement a loader once it's designed and specced. But whether they will be adopted by, say, Node.js (by supplying their own loader implementation), or the 80K packages on npm, or by the developers who are currently using AMD, or the developers who are currently just happy with script tags, is another question. Any claims otherwise are tendentious speculation, to borrow a phrase. Implementors and proponents of legacy systems always fight for their point of view. It's natural and valuable input. But at this point we are speculating about tendencies of developers, not arguing about technical feasibility. Some node developers will never switch; some devs will always use script tags; some business apps will be written in COBOL. It's ok. jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Jeremy Martin 661.312.3853 http://devsmash.com @jmar777 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: TC39 vs the community
On Jun 20, 2014 11:39 AM, John Barton johnjbar...@google.com wrote: I started out with a similar opinion. Then I wrote some ES6 code. What we need now is experience from using ES6-modules. We have plenty of decent implementations. We've built nodejs and browser applications based on ES6 modules. That experience shows that the ES6 solution is modestly superior to any ES5 solution. Moreover the ES6 solution interoperates with the main ES5 solutions. Are there projects which attempted to use ES6 modules but where unable to succeed because of technical barriers? It would certainly be helpful if there was a migration doc written that carefully explained the best practices way to allow your node package/script-tag library/amd module/commonjs module to support ES6 modules as well, in the spirit of the one-liner amd or node.js or... prefixes that are commonly used. --scott ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: TC39 vs the community
On Fri, Jun 20, 2014 at 11:39 AM, John Barton johnjbar...@google.com wrote: I started out with a similar opinion. Then I wrote some ES6 code. What we need now is experience from using ES6-modules. We have plenty of decent implementations. We've built nodejs and browser applications based on ES6 modules. That experience shows that the ES6 solution is modestly superior to any ES5 solution. Moreover the ES6 solution interoperates with the main ES5 solutions. Are there projects which attempted to use ES6 modules but where unable to succeed because of technical barriers? As a developer currently writing ES5 code, what's the best way to try out writing ES6 code that uses modules? Every time I try and look at bootstrapping ES6 with modules, I can't figure it out. A Get Started Trying It Out guide would go a long way, I feel. jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Jasper ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: TC39 vs the community
A minimal, pragmatic and well integrated solution is the ES6 Module Transpiler: https://github.com/square/es6-module-transpiler Additionally, Addy Osmani maintains a comprehensive list of tools: https://github.com/addyosmani/es6-tools Axel On Jun 20, 2014, at 19:54 , Jasper St. Pierre jstpie...@mecheye.net wrote: On Fri, Jun 20, 2014 at 11:39 AM, John Barton johnjbar...@google.com wrote: I started out with a similar opinion. Then I wrote some ES6 code. What we need now is experience from using ES6-modules. We have plenty of decent implementations. We've built nodejs and browser applications based on ES6 modules. That experience shows that the ES6 solution is modestly superior to any ES5 solution. Moreover the ES6 solution interoperates with the main ES5 solutions. Are there projects which attempted to use ES6 modules but where unable to succeed because of technical barriers? As a developer currently writing ES5 code, what's the best way to try out writing ES6 code that uses modules? Every time I try and look at bootstrapping ES6 with modules, I can't figure it out. A Get Started Trying It Out guide would go a long way, I feel. -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: TC39 vs the community
I am trying to stay outside this discussion as much as I can but there is a specific sentence that I'd like to understand: On Fri, Jun 20, 2014 at 8:39 AM, John Barton johnjbar...@google.com wrote: The ES5-module using community tried, valiantly, to reach a compromise module solution. They were not successful. how 80K modules mentioned by Domenic, the concrete adoption of CommonJS or the usage of Browserify for most of the web, can be defined exactly a failure? I am not sure ES6 modules have been overlooked since the beginning but I believe that the rest of the real-world in production out there will keep doing just fine with current inline or AMD based `require(module)` logic. A new ES6 syntax, unfortunately unable to be brought over a UML (Unified Module Loader) as it has done before, will also take much longer to became a de-facto standard as `require` has become these days. Here probably the community sentiment Domenic mentioned, everyone I know somehow applauded fat arrow, nobody I know reacted differently from WTF?!? about ES6 modules. That being said, as complex and powerful APIs can be wrapped and brought to simpler libraries, maybe we actually will keep using `require` but with `import ES6 from module` behind the scene so everyone might win? Best Regards ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: TC39 vs the community
On Fri, Jun 20, 2014 at 2:03 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: I am trying to stay outside this discussion as much as I can but there is a specific sentence that I'd like to understand: On Fri, Jun 20, 2014 at 8:39 AM, John Barton johnjbar...@google.com wrote: The ES5-module using community tried, valiantly, to reach a compromise module solution. They were not successful. how 80K modules mentioned by Domenic, the concrete adoption of CommonJS or the usage of Browserify for most of the web, can be defined exactly a failure? Individually both node modules and amd modules are a huge success. I was only referring to the unsuccessful effort at convergence. I am not sure ES6 modules have been overlooked since the beginning but I believe that the rest of the real-world in production out there will keep doing just fine with current inline or AMD based `require(module)` logic. A new ES6 syntax, unfortunately unable to be brought over a UML (Unified Module Loader) as it has done before, will also take much longer to became a de-facto standard as `require` has become these days. Here probably the community sentiment Domenic mentioned, everyone I know somehow applauded fat arrow, nobody I know reacted differently from WTF?!? about ES6 modules. That being said, as complex and powerful APIs can be wrapped and brought to simpler libraries, maybe we actually will keep using `require` but with `import ES6 from module` behind the scene so everyone might win? To the best of my knowledge, nothing in ES6 prevents you from continuing to use `require()`. If you think require() is the perfect module system, then use it. I think the ES6 module system is better and I plan to use it. If we ever stop talking about it and ship it. jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: TC39 vs the community
I think tools made `require` the winning choice but about having both I am
not sure I've read about dynamic folder such:
`import _ from loDashFolder`
if that's a thing then
```
var require = function (fromWhere) {
return import _ from loDashFolder
};
```
or whatever will be
Best Regards
On Fri, Jun 20, 2014 at 2:29 PM, John Barton johnjbar...@google.com wrote:
On Fri, Jun 20, 2014 at 2:03 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I am trying to stay outside this discussion as much as I can but there is
a specific sentence that I'd like to understand:
On Fri, Jun 20, 2014 at 8:39 AM, John Barton johnjbar...@google.com
wrote:
The ES5-module using community tried, valiantly, to reach a compromise
module solution. They were not successful.
how 80K modules mentioned by Domenic, the concrete adoption of CommonJS
or the usage of Browserify for most of the web, can be defined exactly a
failure?
Individually both node modules and amd modules are a huge success. I was
only referring to the unsuccessful effort at convergence.
I am not sure ES6 modules have been overlooked since the beginning but I
believe that the rest of the real-world in production out there will keep
doing just fine with current inline or AMD based `require(module)` logic.
A new ES6 syntax, unfortunately unable to be brought over a UML (Unified
Module Loader) as it has done before, will also take much longer to became
a de-facto standard as `require` has become these days.
Here probably the community sentiment Domenic mentioned, everyone I
know somehow applauded fat arrow, nobody I know reacted differently from
WTF?!? about ES6 modules.
That being said, as complex and powerful APIs can be wrapped and brought
to simpler libraries, maybe we actually will keep using `require` but with
`import ES6 from module` behind the scene so everyone might win?
To the best of my knowledge, nothing in ES6 prevents you from continuing
to use `require()`. If you think require() is the perfect module system,
then use it. I think the ES6 module system is better and I plan to use
it. If we ever stop talking about it and ship it.
jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: TC39 vs the community
typo ...
```
var require = function (fromWhere) {
return import * from fromWhere
};
```
or something similar
On Fri, Jun 20, 2014 at 3:14 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I think tools made `require` the winning choice but about having both I am
not sure I've read about dynamic folder such:
`import _ from loDashFolder`
if that's a thing then
```
var require = function (fromWhere) {
return import _ from loDashFolder
};
```
or whatever will be
Best Regards
On Fri, Jun 20, 2014 at 2:29 PM, John Barton johnjbar...@google.com
wrote:
On Fri, Jun 20, 2014 at 2:03 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I am trying to stay outside this discussion as much as I can but there
is a specific sentence that I'd like to understand:
On Fri, Jun 20, 2014 at 8:39 AM, John Barton johnjbar...@google.com
wrote:
The ES5-module using community tried, valiantly, to reach a compromise
module solution. They were not successful.
how 80K modules mentioned by Domenic, the concrete adoption of CommonJS
or the usage of Browserify for most of the web, can be defined exactly a
failure?
Individually both node modules and amd modules are a huge success. I was
only referring to the unsuccessful effort at convergence.
I am not sure ES6 modules have been overlooked since the beginning but I
believe that the rest of the real-world in production out there will keep
doing just fine with current inline or AMD based `require(module)` logic.
A new ES6 syntax, unfortunately unable to be brought over a UML (Unified
Module Loader) as it has done before, will also take much longer to became
a de-facto standard as `require` has become these days.
Here probably the community sentiment Domenic mentioned, everyone I
know somehow applauded fat arrow, nobody I know reacted differently from
WTF?!? about ES6 modules.
That being said, as complex and powerful APIs can be wrapped and brought
to simpler libraries, maybe we actually will keep using `require` but with
`import ES6 from module` behind the scene so everyone might win?
To the best of my knowledge, nothing in ES6 prevents you from continuing
to use `require()`. If you think require() is the perfect module system,
then use it. I think the ES6 module system is better and I plan to use
it. If we ever stop talking about it and ship it.
jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: ModuleImport
-Original Message-
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
Sébastien Cevey
Sent: Friday, June 20, 2014 3:46 AM
To: Axel Rauschmayer
Cc: es-discuss list
Subject: Re: ModuleImport
On 20 June 2014 11:39, Axel Rauschmayer a...@rauschma.de wrote:
The `*' symbol universally represents a glob of everything, but
when used to import from a module that has multiple exports, you
won't get everything, you will get either the single default export
(if there is
one) or nothing.
What gives you that impression? Quoting David’s original email:
```js
import * as fs from fs; // importing the named exports as an object
import Dict from dict; // importing a default export, same as ever
```
With all due respect, why is it that we cannot change the specification to
allow `import name from module` for both the default export (for single
export modules) and the Module object (for multi-named export modules). The
same question goes for using `import { name as name } from module` for
both. As specified, a default export is equivalent to a Module object with a
default property, and as a result requires special handling with respect to
how it is bound to the _ImportBinding_ in `import name from module`. Wouldn't
it make sense to simplify the syntax and expand the static and runtime
semantics for imports? Are we sure that the current semantics are the right
approach that we should shoehorn the syntax into?
Is it imperative for module authors to be able to provide both a default export
*and* named exports within the same module? From most of the comments in this
thread, it seems that expected module use falls into two categories:
Single-export modules and Multi-export modules. Is there a use-case in the wild
(via ES6 module transpilers) where a single module today uses both a default
export as well as named exports?
With respect to Node libraries, I often see one of three approaches to
exporting from a module:
_Named Exports_:
```
exports.foo = 1;
// or
module.exports.foo = 1;
```
_Single Export Object_:
```
module.exports = {
foo: 1,
bar: function() {}
}
```
_Single Export Function_:
```
module.exports = function() { }
```
In Node, if you wanted to have a default export that is a function, but also
have additional exports you would most likely add them as data properties on
the function:
```
module.exports = function() {}
module.exports.foo = 1;
```
Given that, why not simplify the syntax and semantics to just the following
three forms:
```
import module; // imports the module but does not perform binding
import name from module; // imports the module (either the default export or
a module object with the named exports, see below)
import { name1, name2 as otherName } from module; // imports members of the
module.
```
Simplifying this requires the following (approximate) changes in semantics:
* Either (A) a module cannot have *both* a default export and named exports,
_or_..
* (B) A modules named exports become attached properties of the default export
if provided.
* If (B), it becomes an runtime error to add a default export after a named
export, and a runtime error to add a named export if the default export is not
an Object.
* The ImportBinding (`name` above) becomes bound to a [[Value]] property of an
(not part of the current spec) Import exotic object.
* When the Module exotic object is loaded, if it has a property named
default, that becomes the value of the [[Value]] property of the Import
exotic object.
* If the Module exotic object does not have a property named default, the
Module itself becomes the value of the [[Value]] property of the Import exotic
object.
* NamedImports now points to bindings to the [[Value]] property of the Import
exotic object. If you want both a default export and named exports, attach the
named exports as properties of the default export.
With the above changes, whether you're using a default export or named exports
becomes transparent to the developer. If the developer _really_ wants the
module object, they could fall back to:
```
import module;
var name = System.get(module); // Returns the Module object without the
transformations applied from above.
```
The above is a rough approximation of the semantics changes. If anyone finds
merit to this proposal, I'll find some time this weekend to write out exactly
what kind of changes there would need to be in the static and runtime semantics
in the current spec. The overall goal is to keep the import syntax simple and
expand the static and runtime semantics to support that simplicity. This
includes continuing to support the ability to handle cyclic dependencies.
Engine authors will need to write the code for the import semantics once, while
the development community will use the import syntax over and over for some
time to come. It seems
Re: ModuleImport
ES6 already has what you want:
_Named Exports_:
export var foo = 1;
_Single Export Object_:
export var moduleName = {
foo: 1,
bar: function() {}
};
_Single Export Function_:
export function fName() { }
And even cooler, the syntax for import is uniform,
import {foo} from './namedExport';
import {moduleName} from './singleExportObject';
import {fName} from './singleExportFunction';
On Fri, Jun 20, 2014 at 3:21 PM, Ron Buckton rbuck...@chronicles.org
wrote:
-Original Message-
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
Sébastien Cevey
Sent: Friday, June 20, 2014 3:46 AM
To: Axel Rauschmayer
Cc: es-discuss list
Subject: Re: ModuleImport
On 20 June 2014 11:39, Axel Rauschmayer a...@rauschma.de wrote:
The `*' symbol universally represents a glob of everything, but
when used to import from a module that has multiple exports, you
won't get everything, you will get either the single default export
(if there is
one) or nothing.
What gives you that impression? Quoting David’s original email:
```js
import * as fs from fs; // importing the named exports as an object
import Dict from dict; // importing a default export, same as ever
```
With all due respect, why is it that we cannot change the specification to
allow `import name from module` for both the default export (for single
export modules) and the Module object (for multi-named export modules). The
same question goes for using `import { name as name } from module` for
both. As specified, a default export is equivalent to a Module object with
a default property, and as a result requires special handling with
respect to how it is bound to the _ImportBinding_ in `import name from
module`. Wouldn't it make sense to simplify the syntax and expand the
static and runtime semantics for imports? Are we sure that the current
semantics are the right approach that we should shoehorn the syntax into?
Is it imperative for module authors to be able to provide both a default
export *and* named exports within the same module? From most of the
comments in this thread, it seems that expected module use falls into two
categories: Single-export modules and Multi-export modules. Is there a
use-case in the wild (via ES6 module transpilers) where a single module
today uses both a default export as well as named exports?
With respect to Node libraries, I often see one of three approaches to
exporting from a module:
_Named Exports_:
```
exports.foo = 1;
// or
module.exports.foo = 1;
```
_Single Export Object_:
```
module.exports = {
foo: 1,
bar: function() {}
}
```
_Single Export Function_:
```
module.exports = function() { }
```
In Node, if you wanted to have a default export that is a function, but
also have additional exports you would most likely add them as data
properties on the function:
```
module.exports = function() {}
module.exports.foo = 1;
```
Given that, why not simplify the syntax and semantics to just the
following three forms:
```
import module; // imports the module but does not perform binding
import name from module; // imports the module (either the default
export or a module object with the named exports, see below)
import { name1, name2 as otherName } from module; // imports members
of the module.
```
Simplifying this requires the following (approximate) changes in semantics:
* Either (A) a module cannot have *both* a default export and named
exports, _or_..
* (B) A modules named exports become attached properties of the default
export if provided.
* If (B), it becomes an runtime error to add a default export after a
named export, and a runtime error to add a named export if the default
export is not an Object.
* The ImportBinding (`name` above) becomes bound to a [[Value]] property
of an (not part of the current spec) Import exotic object.
* When the Module exotic object is loaded, if it has a property named
default, that becomes the value of the [[Value]] property of the Import
exotic object.
* If the Module exotic object does not have a property named default,
the Module itself becomes the value of the [[Value]] property of the Import
exotic object.
* NamedImports now points to bindings to the [[Value]] property of the
Import exotic object. If you want both a default export and named exports,
attach the named exports as properties of the default export.
With the above changes, whether you're using a default export or named
exports becomes transparent to the developer. If the developer _really_
wants the module object, they could fall back to:
```
import module;
var name = System.get(module); // Returns the Module object without the
transformations applied from above.
```
The above is a rough approximation of the semantics changes. If anyone
finds merit to this proposal,
Re: TC39 vs the community
On Friday, June 20, 2014 7:15 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
typo ...
```
var require = function (fromWhere) {
return import * from fromWhere
};
```
That's not valid ES6. It's specified that:
- Import and export statements can only be top level statements
- The module name must be a string literal.
- Import * is not specified.
ES6 modules are designed to be static. So no, you can't use import statements
under the hood in require(). But you can set up things so that you can use
import to import CommonJS modules.
Juan___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: ModuleImport
From: John Barton [mailto:johnjbar...@google.com]
Sent: Friday, June 20, 2014 3:48 PM
ES6 already has what you want:
_Named Exports_:
export var foo = 1;
_Single Export Object_:
export var moduleName = {
foo: 1,
bar: function() {}
};
_Single Export Function_:
export function fName() { }
And even cooler, the syntax for import is uniform,
import {foo} from './namedExport';
import {moduleName} from './singleExportObject';
import {fName} from './singleExportFunction';
I'm not stating that I specifically want anything here, but was rather
recommending an alternative approach to the single export vs named export
debate and the removal of the ModuleImport production. David's mail was
proposing the addition of the following syntax:
```
import * as fs from fs
```
This is designed to work around the fact that without ModuleImport, there's no
simple way to get the module object for the named exports. What you really want
to write is:
```
import fs from fs;
```
However, the current semantics don't allow this. David proposed the new syntax
as a replacement for ModuleImport. My only issue is that for the end user this
could be confusing, and its possibly future-hostile for refactoring.
If I have a library today that uses an object literal as a default export in
Node, and I want to migrate to ES6, the easiest approach is to just replace
`module.exports =` with `export default`. My consumers would happy use `import
foo from foo`. If I later want to move to named exports, I would break my
consumers as they would have to change this to `import * as foo from foo`.
The whole reason for this is that there is a semantic distinction with how a
default export is handled vs. how named exports are handled.
If I were to use TypeScript's syntax for exports and imports, changing from a
default export to named exports results in no change for the consumer:
[before.ts]
```
export = {
foo: 1,
bar() {}
}
```
[after.ts]
```
export var foo = 1;
export function bar() {}
```
[consumer.ts]
```
import before = require(before);
import after = require(after);
before.foo; // 1
before.bar; // function bar() {}
after.foo // 1
after.bar; // function bar() {}
```
Albeit, TypeScript does not have a Module exotic object, nor does it have
mutable bindings, nor an ImportList in its import clause. That said, as far as
the consumer is concerned there's no real distinction between the default
export approach in before.ts and the named export approach in after.ts. We
have this distinction in ES6 because it was designed that way to support
mutable bindings and cyclic dependencies. I'm proposing that we come up with
alternative semantics that preserve that approach while keeping the import
syntax simple.
As a module consumer, I would constantly need to be aware of whether I need to
use the `import * as foo from foo` syntax or the `import foo from foo`
syntax. Where in Node I would use `require(foo)` for both cases. By changing
the semantics of ImportDeclaration in ES6 and using a simpler syntax, we could
would save developers the cognitive cost of determining which import syntax to
among two very similar forms, as well as supporting the ability for a module
author to refactor their module from a default export to named exports for the
single-export-as-object case without affecting their consumers.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ModuleImport
On Fri, Jun 20, 2014 at 4:17 PM, Ron Buckton rbuck...@chronicles.org
wrote:
From: John Barton [mailto:johnjbar...@google.com]
Sent: Friday, June 20, 2014 3:48 PM
ES6 already has what you want:
_Named Exports_:
export var foo = 1;
_Single Export Object_:
export var moduleName = {
foo: 1,
bar: function() {}
};
_Single Export Function_:
export function fName() { }
And even cooler, the syntax for import is uniform,
import {foo} from './namedExport';
import {moduleName} from './singleExportObject';
import {fName} from './singleExportFunction';
I'm not stating that I specifically want anything here, but was rather
recommending an alternative approach to the single export vs named export
debate and the removal of the ModuleImport production.
Sorry, I did understand that. I was (cryptically) recommending that
removing ModuleImport and `export default` until a later date gives us a
good-enough solution to the cases you outline. These features can be added
at a later very easily and since they would be based on real users asking
for more features we could move on them quickly.
David's mail was proposing the addition of the following syntax:
```
import * as fs from fs
```
This is designed to work around the fact that without ModuleImport,
there's no simple way to get the module object for the named exports. What
you really want to write is:
```
import fs from fs;
```
However, the current semantics don't allow this. David proposed the new
syntax as a replacement for ModuleImport. My only issue is that for the end
user this could be confusing, and its possibly future-hostile for
refactoring.
So let's just remove it and export default and go. No confusion. We make
progress. We study real feedback. We reconsider.
If I have a library today that uses an object literal as a default export
in Node, and I want to migrate to ES6, the easiest approach is to just
replace `module.exports =` with `export default`.
Easing migration is a great goal for the next release. We can refine
ModuleImport between now and then.
My consumers would happy use `import foo from foo`. If I later want to
move to named exports, I would break my consumers as they would have to
change this to `import * as foo from foo`. The whole reason for this is
that there is a semantic distinction with how a default export is handled
vs. how named exports are handled.
Exactly. So don't allow default export. Presto, problem solved.
If I were to use TypeScript's syntax for exports and imports, changing
from a default export to named exports results in no change for the
consumer:
[before.ts]
```
export = {
foo: 1,
bar() {}
}
```
[after.ts]
```
export var foo = 1;
export function bar() {}
```
[consumer.ts]
```
import before = require(before);
import after = require(after);
before.foo; // 1
before.bar; // function bar() {}
after.foo // 1
after.bar; // function bar() {}
```
Albeit, TypeScript does not have a Module exotic object, nor does it have
mutable bindings, nor an ImportList in its import clause. That said, as far
as the consumer is concerned there's no real distinction between the
default export approach in before.ts and the named export approach in
after.ts. We have this distinction in ES6 because it was designed that way
to support mutable bindings and cyclic dependencies. I'm proposing that we
come up with alternative semantics that preserve that approach while
keeping the import syntax simple.
I think both export default/module import and cyclic dependency support are
marginal features that cause as many wacky problems as the solve. They just
don't matter one way or another. The export default/module-import are easy
to add later: removing them now is simple. Changing the semantics means
redesigning modules.
As a module consumer, I would constantly need to be aware of whether I
need to use the `import * as foo from foo` syntax or the `import foo from
foo` syntax. Where in Node I would use `require(foo)` for both cases.
By changing the semantics of ImportDeclaration in ES6 and using a simpler
syntax, we could would save developers the cognitive cost of determining
which import syntax to among two very similar forms, as well as supporting
the ability for a module author to refactor their module from a default
export to named exports for the single-export-as-object case without
affecting their consumers.
Omitting export default and module-import achieves the same cognitive
savings.
jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
