Infrequently Noted

Alex Russell on browsers, standards, and the process of progress.

Why "class" Doesn't Mean What You Think It Means

There's a lot of "don't turn it into Java!" in the comments on my last post, and I feel it needs a response -- and not because I think there's anything to like about Java's class or type systems (perhaps that they exist at all? I'm torn on even that).

Lets look at some possible ES.next code and walk through how it relates to today's equivalent JS:

module widgets {
  // ...

export class DropDownButton extends Widget { constructor(attributes) { super(attributes); this.buildUI(); }

buildUI() { this.domNode.onclick = (e) -> { // ... }; } } }

Ignoring the semantic improvements of Harmony modules over the module patterns we're using today, we can see a pretty straight-up de-sugaring of that to today's JS with an emphasis on the many and varied uses of the word function:

var widgets = (function(global) {
  // ...

function DropDownButton(attributes) { Widget.call(this, attributes); this.buildUI(); }

DropDownButton.prototype = Object.create(Widget.prototype, { constructor: { value: DropDownButton }, buildUI: { value: function(e) { this.domNode.onclick = function(e) { // ... } } } }); })(this);

What you should take away from this isn't that we're turning JS into Java, it's that we're making it easier to read, AND THAT'S ALL. Once more for effect: what class means in ES6 is function. Or at least one of the things you currently do with function.

Better yet, we're blessing a single pattern which you can use with old-style classes just as easily as you do today. I'll leave it as an exercise for you to name all the different class patterns and systems that do nearly the same thing in slightly incompatible ways today. It's a very long list.

If you like JS, and you like functions + prototypes (I do!), you have nothing to fear from the sugar we're adding in ES6.

Update: A lunchtime conversation here at DojoConf today reminded me of perhaps the largest thing that this new system doesn't do; ES.next aren't tied to a Java-like type system. Many of the conjoined fears of Java come from the very real pain created by a strict, nominal type system, and nobody in the committee is proposing a mistake like that -- least of all me.