Classes: suggestions for improvement

Axel Rauschmayer axel at rauschma.de
Sun Jun 12 16:13:27 PDT 2011


>> Something about classes in JS makes me sad, an emotional effect I can't explain fully. In part I fear the "lint brush" aspect I mentioned in the thread Irakli just followed up: class syntax will grow lots of hair over time. In part I think class is the wrong word, as cowboyd tweeted (see below).
>> 
>> Mainly I think we are still finding class syntax, not just the keyword, a bit hard to fit to the prototypal pattern. The super keyword in limited expression forms is no problem. The extends and prototype "Heritage" clause in the class head is ok.
>> 
>> The constructor flows from the prototype-methods-at-class-element-position design, but starts to rankle, if only because of the name's length. As you can see in my posts today, it seems to go downhill from there. And we're still trying to find a better syntax than the "static" keyword.
> 
> Let's say we can make classes mean what we want. Per the agreement to promote them into Harmony with open issues, we are "close enough".
> 
> But we still need to nail those open issues. This requires considering alternatives carefully and writing down everything pro and con. It'll be tedious work, without easy answers (at first). I'm game to do it here, although others may fear the Inbox load.
> 
> Reflecting on classes in JS, at a high level I feel we are falling into the gravity well of a dying star. It could supernova, in which case we will be burned. Or it could black-hole and we'll get rent by tides before going somewhere else ;-).
> 
> Ok, fun metaphor but I'm not totally kidding. The gravity well is created by the mass of "class expectations" from other languages, plus de-facto "prototypal" and other patterns in JS. Heavy.


Two observations:

- Object.create() seems to have started something truly prototypal in JavaScript that never quite got finished. If there was a way to bring more Self to JavaScript (instead of more Java, Python, or Ruby) when it comes to inheritance, I would be all for it, but it always sounded to me like most people don’t want that.

- What I find most difficult about the current way of doing inheritance is that the constructor "is" the type, while the prototype would be a much better choice.

var SkinnedMesh = THREE.Mesh <| {
  constructor(geometry, materials) {
    super.constructor(geometry, materials);
 
    this.identityMatrix = new THREE.Matrix4();
    this.bones = [];
    this.boneMatrices = [];
    ...
  }
 
  update(camera) {
    ...
    super.update();
  }
}

var sm = new SkinnedMesh(...);
sm instanceof SkinnedMesh // true


The only things that change from ES5 are:
- Adapting new and instanceof to accept objects (in addition to constructor functions)
- Some kind of proto operator (<| in the code above)
- super.foo(x,y) is syntactic sugar for Object.getPrototypeOf(SkinnedMesh).foo.call(this, x, y)
    - I have no idea how to get SkinnedMesh in there, but concise object literals make a similar proposal, so there must be a solution.
- The above obviously profits from anything offered by concise object literals (and in fact already uses the more compact way to write methods).

I hope this makes sense. A side benefit would be that type/class variables (such as Math.PI) would automatically be inherited to subtypes/subclasses.

-- 
Dr. Axel Rauschmayer

axel at rauschma.de
twitter.com/rauschma

home: rauschma.de
blog: 2ality.com





More information about the es-discuss mailing list