Do Anonymous Exports Solve the Backwards Compatibility Problem?

Brendan Eich brendan at mozilla.com
Thu Dec 20 13:29:02 PST 2012


Andreas Rossberg wrote:
> On 20 December 2012 19:39, Brendan Eich <brendan at mozilla.com 
> <mailto:brendan at mozilla.com>> 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 approach invariably leads to
>         baroque, kitchen sink style language constructs that yet scale
>         poorly to the general use case. (The typical notion of a class
>         in mainstream OO languages is a perfect example.)
>
>
>     That's a good concern, but not absolute. How do you deal with the
>     counterargument that, without macros, the overhead of users having
>     to glue together the orthogonal concerns into a compound cliché is
>     too high and too error-prone?
>
>         One of the nicer aspects of pre-ES6 JavaScript is that it
>         doesn't have too much of that sort of featurism.
>
>
>     So people keep telling me. Yet I see ongoing costs from all the
>     module-pattern, power-constructor-pattern, closure-pattern lack of
>     learning, slow learning, mis-learning, fetishization, and
>     bug-habitat surface area.
>
>
> Sorry, what I wrote may have been a bit unclear. I didn't try to argue 
> against features in general. I agree that it is important to grow a 
> language where the need arises. What I argued against was the 
> particular approach of accumulating all sorts of ad hoc features and 
> extensions in one monolithic language concept.

Yes, we have too much of that in how multifarious and compound JS's 
function is already. People use it for constructors, procedures, 
functions, closures, modules, statics, and more. You could say this is 
all fine (I don't object in general!) but it is an exercise in 
pattern-building, of necessity. And frequently used, verbose and 
error-prone patterns are definitely feature requests.

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-quite-the-same things where the differences seem 
likely (to me at any rate) to bite back. We could defer it with a 
strawman that implementors could agree on as an experimental extension, 
to prove or disprove the idea. That seems better for ES6 and Harmony.

/be


More information about the es-discuss mailing list