Re: Do Anonymous Exports Solve the Backwards Compatibility Problem?

2012-12-21 Thread Claus Reinke
* The module loader API exposes a "runtime" API that is not new syntax, just an API. From some earlier Module Loader API drafts, I thought it was something like System.get() to get a dependency, System.set() to set the value that will be used as the export. * Base libraries that need to live in c

Re: Do Anonymous Exports Solve the Backwards Compatibility Problem?

2012-12-20 Thread Domenic Denicola
On Dec 20, 2012, at 19:02, "David Herman" wrote: > On Dec 20, 2012, at 1:29 PM, Brendan Eich wrote: > >> So the particular approach -- in particular -- that you are questioning is >> adding export = to ES6 modules. I agree it is ad-hoc. It also seems likely >> to confuse, compared to the self

Re: Do Anonymous Exports Solve the Backwards Compatibility Problem?

2012-12-20 Thread David Herman
On Dec 20, 2012, at 1:29 PM, Brendan Eich wrote: > So the particular approach -- in particular -- that you are questioning is > adding export = to ES6 modules. I agree it is ad-hoc. It also seems likely to > confuse, compared to the self-hosted NPM precedent. It's one of those > almost-but-not

Re: Do Anonymous Exports Solve the Backwards Compatibility Problem?

2012-12-20 Thread Brendan Eich
Andreas Rossberg wrote: On 20 December 2012 19:39, Brendan Eich > wrote: Andreas Rossberg wrote: More importantly, though, convention is one thing, baking it into the language another. I've become deeply skeptical of shoe-horning orthogona

Re: Do Anonymous Exports Solve the Backwards Compatibility Problem?

2012-12-20 Thread Andreas Rossberg
On 20 December 2012 19:39, Brendan Eich wrote: > Andreas Rossberg wrote: > >> More importantly, though, convention is one thing, baking it into the >> language another. I've become deeply skeptical of shoe-horning orthogonal >> concerns into one "unified" concept at the language level. IME, that

Re: Do Anonymous Exports Solve the Backwards Compatibility Problem?

2012-12-20 Thread James Burke
On Thu, Dec 20, 2012 at 11:51 AM, Sam Tobin-Hochstadt wrote: > - I don't see what a mutable `exports` object would add on top of > this system, but maybe I'm not understanding what you're saying. It is one way to allow circular dependencies in CommonJS/Node/AMD systems. The other way is to call

Re: Do Anonymous Exports Solve the Backwards Compatibility Problem?

2012-12-20 Thread Sam Tobin-Hochstadt
On Thu, Dec 20, 2012 at 2:44 PM, James Burke wrote: > > If that all of the above holds true (getting clarification on the > Module Loader API is needed), Just to clarify about the Module Loader API: - System.set/System.get are very much still a part of the design. In fact, the loader design ha

Re: Do Anonymous Exports Solve the Backwards Compatibility Problem?

2012-12-20 Thread James Burke
On Thu, Dec 20, 2012 at 8:22 AM, Kevin Smith wrote: > This is exactly the use case that my OP addresses. The logic goes like > this: in order to apply that boilerplate, you have to know whether the > module is ES5 or ES6. In order to know that, you have to parse it. > Pre-parsing every single m

Re: Do Anonymous Exports Solve the Backwards Compatibility Problem?

2012-12-20 Thread Brendan Eich
Andreas Rossberg wrote: More importantly, though, convention is one thing, baking it into the language another. I've become deeply skeptical of shoe-horning orthogonal concerns into one "unified" concept at the language level. IME, that approach invariably leads to baroque, kitchen sink style

Re: Do Anonymous Exports Solve the Backwards Compatibility Problem?

2012-12-20 Thread Andreas Rossberg
On 20 December 2012 14:17, Sam Tobin-Hochstadt wrote: > We want to support *both* a syntax for 'import a module, and bind a > particular identifier to the single anonymous export' and a syntax for > 'import a module, and bind an identifier to the module instance > object'. We could make these d

Re: Do Anonymous Exports Solve the Backwards Compatibility Problem?

2012-12-20 Thread Sam Tobin-Hochstadt
On Thu, Dec 20, 2012 at 11:22 AM, Kevin Smith wrote: >> The latter scenario isn't important for the 'module exports a single >> function which is identified with the module' case, but it is >> important for gradual migration to ES6. It's much easier to convert an >> ES5 library that attaches a sin

Re: Do Anonymous Exports Solve the Backwards Compatibility Problem?

2012-12-20 Thread Kevin Smith
The latter scenario isn't important for the 'module exports a single > function which is identified with the module' case, but it is > important for gradual migration to ES6. It's much easier to convert an > ES5 library that attaches a single value to the global object to a > single-export module b

Re: Do Anonymous Exports Solve the Backwards Compatibility Problem?

2012-12-20 Thread Sam Tobin-Hochstadt
On Thu, Dec 20, 2012 at 5:54 AM, Andreas Rossberg wrote: > On 20 December 2012 05:24, Brendan Eich wrote: >> >> Domenic Denicola wrote: IMO this is undesirable. In such a situation, modules can no longer be abstraction boundaries. Instead you must peek inside each module and see >>

Re: Do Anonymous Exports Solve the Backwards Compatibility Problem?

2012-12-20 Thread Andreas Rossberg
On 20 December 2012 05:24, Brendan Eich wrote: > Domenic Denicola wrote: > >> IMO this is undesirable. In such a situation, modules can no longer be >>> abstraction boundaries. Instead you must peek inside each module and see >>> which form it exported itself using. >>> >> > You have to know what

Re: Do Anonymous Exports Solve the Backwards Compatibility Problem?

2012-12-20 Thread Andreas Rossberg
On 19 December 2012 23:05, David Herman wrote: > On Dec 19, 2012, at 12:59 PM, Andreas Rossberg > wrote: > > > It's also worth noting that Dave's comparison is somewhat inaccurate. > The convention is used to name the _primary_ abstract type defined by a > module, not the _only_ export > > That

Re: Do Anonymous Exports Solve the Backwards Compatibility Problem?

2012-12-19 Thread Brendan Eich
Brendan Eich wrote: exports alias and mutation makes this observable. Er, "imports alias exports and " /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Do Anonymous Exports Solve the Backwards Compatibility Problem?

2012-12-19 Thread Brendan Eich
Domenic Denicola wrote: -Original Message- From: es-discuss-boun...@mozilla.org [mailto:es-discuss- boun...@mozilla.org] On Behalf Of Brendan Eich Sent: Wednesday, December 19, 2012 23:11 In a thread you may not have caught up on, Andreas did argue for a special form such as modu

RE: Do Anonymous Exports Solve the Backwards Compatibility Problem?

2012-12-19 Thread Domenic Denicola
> -Original Message- > From: es-discuss-boun...@mozilla.org [mailto:es-discuss- boun...@mozilla.org] > On Behalf Of Brendan Eich > Sent: Wednesday, December 19, 2012 23:11 > In a thread you may not have caught up on, Andreas did argue for a special > form such as > module foo at "foo";

Re: Do Anonymous Exports Solve the Backwards Compatibility Problem?

2012-12-19 Thread Brendan Eich
In a thread you may not have caught up on, Andreas did argue for a special form such as module foo at "foo"; for anonymous import, so that the system can check that "foo" indeed does export = ... and throw otherwise. Sorry if you did see this and reply (in which case I missed the reply!). If

Re: Do Anonymous Exports Solve the Backwards Compatibility Problem?

2012-12-19 Thread David Herman
On Dec 19, 2012, at 3:22 PM, David Herman wrote: > On Dec 19, 2012, at 12:05 PM, Andreas Rossberg wrote: > >>> Assigning a single exports also nudges people to make small modules >>> that do one thing. >> It rather nudges people into exporting an object as a module, instead of >> writing a rea

Re: Do Anonymous Exports Solve the Backwards Compatibility Problem?

2012-12-19 Thread David Herman
On Dec 19, 2012, at 12:05 PM, Andreas Rossberg wrote: >> Assigning a single exports also nudges people to make small modules >> that do one thing. > It rather nudges people into exporting an object as a module, instead of > writing a real module. The only "benefit" of that is that they lose all

Re: Do Anonymous Exports Solve the Backwards Compatibility Problem?

2012-12-19 Thread David Herman
On Dec 19, 2012, at 11:44 AM, Kevin Smith wrote: > But that cowpath was only created because of the problems inherent in a > dynamic, variable-copy module system, as I argue here > (https://gist.github.com/4337062). In CommonJS, modules are about variables. > In ES6, modules are about bindin

Re: Do Anonymous Exports Solve the Backwards Compatibility Problem?

2012-12-19 Thread David Herman
On Dec 18, 2012, at 12:56 PM, Kevin Smith wrote: > At first glance, it seems like anonymous exports might provide a way for > pre-ES6 (read: Node) modules and ES6 modules to coexist. That's not what anonymous exports are for. They're there to support the use case of modules that want to suppor

Re: Do Anonymous Exports Solve the Backwards Compatibility Problem?

2012-12-19 Thread David Herman
On Dec 19, 2012, at 12:59 PM, Andreas Rossberg wrote: > It's also worth noting that Dave's comparison is somewhat inaccurate. The > convention is used to name the _primary_ abstract type defined by a module, > not the _only_ export That doesn't disagree with what I said. I don't really get the

Re: Do Anonymous Exports Solve the Backwards Compatibility Problem?

2012-12-19 Thread Kevin Smith
> In summary, I do not believe there is a technical issue with export > assignment and backcompat, which was the what started this thread. Why not? I've attempted to show that it's not possible to correctly use this feature for backward compatibility without parsing the code first. Pre-parsing

Re: Do Anonymous Exports Solve the Backwards Compatibility Problem?

2012-12-19 Thread Andreas Rossberg
On 19 December 2012 21:29, James Burke wrote: > This is illustrated by an example from Dave Herman, for a language > (sorry I do not recall which), where developers ended up using "_t", > or some convention like that, to indicate a single export value that > they did not want to name. As I recall

Re: Do Anonymous Exports Solve the Backwards Compatibility Problem?

2012-12-19 Thread James Burke
On Wed, Dec 19, 2012 at 11:44 AM, Kevin Smith wrote: > But that cowpath was only created because of the problems inherent in a > dynamic, variable-copy module system, as I argue here > (https://gist.github.com/4337062). In CommonJS, modules are about > variables. In ES6, modules are about bindin

Re: Do Anonymous Exports Solve the Backwards Compatibility Problem?

2012-12-19 Thread Andreas Rossberg
On 19 December 2012 20:18, James Burke wrote: > exports assignment is not about backcompat specifically, although it > helps. Exports assignment is more about keeping the anonymous natures > of modules preserved. In ES modules, modules do not name themselves if > it is a single module in a file.

Re: Do Anonymous Exports Solve the Backwards Compatibility Problem?

2012-12-19 Thread Kevin Smith
> Assigning a single exports also nudges people to make small modules > that do one thing. > A Node-ism for which the benefit is not yet proven : ) > It is a design aesthetic that has been established in the JS > community, both in node and in AMD modules, in real code used by many > people. So

Re: Do Anonymous Exports Solve the Backwards Compatibility Problem?

2012-12-19 Thread James Burke
On Tue, Dec 18, 2012 at 12:56 PM, Kevin Smith wrote: > At first glance, it seems like anonymous exports might provide a way for > pre-ES6 (read: Node) modules and ES6 modules to coexist. After all: > > exports = function A() {}; > > just looks so much like: > > module.exports = function A

Do Anonymous Exports Solve the Backwards Compatibility Problem?

2012-12-18 Thread Kevin Smith
At first glance, it seems like anonymous exports might provide a way for pre-ES6 (read: Node) modules and ES6 modules to coexist. After all: exports = function A() {}; just looks so much like: module.exports = function A() {}; But is that the case? Does this oddball syntax actually he