Do Anonymous Exports Solve the Backwards Compatibility Problem?

David Herman dherman at
Wed Dec 19 14:05:30 PST 2012

On Dec 19, 2012, at 12:59 PM, Andreas Rossberg <rossberg at> 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 obsession with "just one value" either (it's some pretty dubious sophistry, IMO). I think the key is when you have a module that provides a primary *abstraction*. That's what I said in the meeting. In ML that can take the form of a type; in JS it can take the form of a constructor, class, and/or function. The concept you end up reaching for is unifying the idea of the module and the abstraction itself. That's what you're doing with .t in ML and that's what's going on in JS with jQuery, node-optimist, etc etc.

Honestly I don't have all that strong feelings about this issue. I think the anonymous export idea is the cleanest approach to support an idiom that fits with JS without ruining it for static exports. I also think JS would be fine without it. I'm almost inclined to just let others fight it out... ;-P


More information about the es-discuss mailing list