Discuss
  • minimal classes

minimal classes

# David Herman (13 years ago)

I've been concerned about the schedule risk of classes for ES.next; following are some thoughts about a minimal class feature that I believe satisfies the most important needs while leaving room for future growth.

I think the bare-minimum requirements of classes would be:

  • declarative class expressions
  • declarative constructor/prototype inheritance (i.e., the extends clause)
  • super-calls
  • declarative methods

Examples:

class C {
    constructor(x, y) {
        this.x = x;
        this.y = y;
    }
    foo() {
        return this.x + this.y;
    }
}

class D extends C {
    constructor() {
        super(0, 0);
    }
    bar() {
        print("hi")
    }
}

I suggest that for ES.next, we completely leave out declarative properties, class properties, or even private data. All of this can be expressed already with imperative features. (Private data can be implemented with private names, and I've come to believe that Object.freeze just simply shouldn't freeze private properties.) That's not to say that these features would never be desirable, but we've so far struggled to come up with something that hangs together. And the features I describe above don't close off these possibilities. I want classes to succeed for ES.next, and even more importantly I want ES.next to succeed and succeed on time.

I'd argue that the minimal feature set described above covers the most important needs:

  • standardizing prototype hierarchies (I'm of the opinion that superclass constructors ought to be the prototype of subclass constructors in order to inherit class properties)
  • providing declarative syntax for initializing the C.prototype object
  • providing idiomatic syntax for calling the superclass constructor
  • enabling instance-private and/or class-private data (via private names)
# Brendan Eich (13 years ago)

On Jun 27, 2011, at 10:00 PM, David Herman wrote:

  • standardizing prototype hierarchies (I'm of the opinion that superclass constructors ought to be the prototype of subclass constructors in order to inherit class properties)

+1

  • providing idiomatic syntax for calling the superclass constructor

But what about subclass method calling superclass method(s)?

# David Herman (13 years ago)
  • providing idiomatic syntax for calling the superclass constructor

But what about subclass method calling superclass method(s)?

In terms of priorities, I think super-constructors are the single most important use case for super. But I think super-methods fall out naturally from the semantics of super, so they could easily be supported.

# Peter Michaux (13 years ago)

On Mon, Jun 27, 2011 at 10:13 PM, Brendan Eich <brendan at mozilla.com> wrote:

On Jun 27, 2011, at 10:00 PM, David Herman wrote:

I've been concerned about the schedule risk of classes for ES.next

Is the timeline posted somewhere?

  • providing idiomatic syntax for calling the superclass constructor

But what about subclass method calling superclass method(s)?

I think this is an essential feature for a class syntax. Calling super for methods is one of the features that JavaScript libraries prioritize very highly. They all have some way of calling super for a method.

Peter

# Brendan Eich (13 years ago)

On Jun 27, 2011, at 10:50 PM, Peter Michaux wrote:

On Mon, Jun 27, 2011 at 10:13 PM, Brendan Eich <brendan at mozilla.com> wrote:

On Jun 27, 2011, at 10:00 PM, David Herman wrote:

I've been concerned about the schedule risk of classes for ES.next

Is the timeline posted somewhere?

We've talked about it since ES5 wrapped up. End of 2013 GA vote on ES.next (let's hope ES6) means spec all but done earlier that year, which means spec feature-complete about now in order to leave time for spec production and prototype implementation with user testing.

We had a cut-off at the last meeting. A few stragglers may special-plead, and we can certainly cut (Dave proposes some reductions within the late-breaking classes).

  • providing idiomatic syntax for calling the superclass constructor

But what about subclass method calling superclass method(s)?

I think this is an essential feature for a class syntax. Calling super for methods is one of the features that JavaScript libraries prioritize very highly. They all have some way of calling super for a method.

I agree that the most minimal classes proposal must allow method super-chaining, not just constructor super-chaining.

In a followup, Dave referenced Allen's super proposal, extended to class methods other than constructor. But we've recently been debating a restriction to allow super(...) only, for same-named method chaining. Not sure where Dave stands on that.

# Allen Wirfs-Brock (13 years ago)

Dave,

I agree with your goal of simplifying things in this area. In that regard, I think you bare-miniumn requirements align quite nicely with "prototypes as classes" as has been recently discussed here. In case you haven't followed all the twists of the discussion, Axel Rauschmayer has a nice overview at www.2ality.com/2011/06/prototypes-as-classes.html . The big hangup with this approach until recently was that it did not seem to fit well with the existing built-ins or constructor patterns. However, it now appears that there is a pretty nice way to integrate the two approaches.

Taking this approach, we would have the full expressiveness of your bare-miniumn classes but achieve it using object literal extensions. There is no need to add a new class declaration form. We would have something that works and feels like classes but which also preserves the prototypal inheritance focus and feel of ES. It also continues to reserve the "class" keyword for future use, if it turns out that this simpler "prototype as classes" approach is inadequate (I don't think this will happen, but it is good to still have a fallback).

As soon as a get a block of time later this week I will write up a "prototype as classes" proposal that covers al the technical edge cases including integration with existing built-ins.