Do Anonymous Exports Solve the Backwards Compatibility Problem?
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?
> 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.
More information about the es-discuss