Do Anonymous Exports Solve the Backwards Compatibility Problem?
jrburke at gmail.com
Wed Dec 19 12:29:17 PST 2012
On Wed, Dec 19, 2012 at 11:44 AM, Kevin Smith <khs4473 at gmail.com> 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 bindings. The difference is subtle,
> but makes all the difference.
Those slightly different things are still about naming, and my reply
was about naming. Whether it is a "variable" or a "binding", end
result is whether the caller of the code need to start with a name
specified by the module or with a name of the caller's choosing. The
same design aesthetics are in play.
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, that language had something
more like "bindings" than "variables". That would be ugly to see a
"_t" convention in JS (IMO).
In summary, I do not believe there is a technical issue with export
assignment and backcompat, which was the what started this thread. A
different argument (and probably different thread) against export
assignment needs to be made, with more details on the actual harm it
If the desire to not have export assignment is a style preference, it
will be hard to make that argument given the style in use in existing
JS, both in node and AMD. Real world use and adoption should have have
more weight when making the style choice.
More information about the es-discuss