Finding a "safety syntax" for classes

Russell Leggett russell.leggett at gmail.com
Mon Mar 19 13:03:58 PDT 2012


The recent discussion “Using Object Literals as Classes” brought up some
key points, but the general feeling I got and agree with is this: we need
to get classes into ES6. As Kevin points out, even if it didn’t have all of
the features (like mixins) that most class libs have, he would use an
extremely minimal class syntax. I think CoffeeScript is proof that others
feel the same way. CoffeeScript classes are just a wrapper around the
“standard” way of making classes and is completely interoperable with
vanilla JS constructor function “classes”. It does not really have bells
and whistles - just a nice declarative syntax, including support for
extension and super.

The subject of classes has come up countless times and still we have no
resolution. Brendan has phrased it as the “goldilocks proposal” - it can’t
be too big or too small, but needs to be “just right”. I would suggest what
we need right now is a different analogy. What we need is the “safety
syntax”. For those unfamiliar with the idea, in the states we have a term
“safety school” - when applying for colleges, it is recommended to apply to
at least one college that you would be satisfied going to and can be almost
guaranteed to get into. This way, worst case scenario, if you don’t get
into all the other schools you like better, at least you can fall back on
your “safety school”.

Is it possible that we can come up with a class syntax that we can all
agree is better than nothing, and importantly, leaves possibilities open
for future enhancement? As a “safety syntax” this doesn’t mean we stop
trying to find a better syntax, it just means that if we don’t find it then
we still have something – something that we can make better in ES7.

I would propose that the absolute minimal requirements would be:

   - has a declaration form that uses the class keyword and an identifier
   to create the class
   - has a body that can include both the constructor function, as well as
   any instance (prototype) methods – including getter and setter properties
   - can declare the class as a subclass of a another class (probably with
   the extends keyword)
   - super is available from any of the methods or constructor function

The following is an example from the CoffeeScript website, and just
converted to what seemed like a logical JS version:

class Animal {

    constructor(name){

        this.name = name;

    }

    move(meters){

        alert(this.name + " moved " + meters + "m.");

    }

}


class Snake extends Animal {

    constructor(name){

        super(name);

    }

    move(){

        alert("Slithering...");

        super.move(5);

    }

}


class Horse extends Animal {

    constructor(name){

        super(name);

    }

    move(){

        alert("Galloping...");

        super.move(45);

    }

}


let sam = new Snake("Sammy the Python");

let tom = new Horse("Tommy the Palomino");

A few things that are different from CoffeeScript:

   - if there is no constructor, it doesn’t automatically pass arguments up
   to the parent constructor. I think that would be nice but more
   controversial.
   - to call super on a method you have to indicate the method super.move
   - while not obvious in the example, I would say the class body should
      - be its own construct, not just an object literal - this makes it
      easier to have methods without ,’s and be future-proof for whatever we
      might want later
      - only allow a constructor function and methods - nothing else. No
      public/private fields. No worrying about var x = {a:b} inside the
      class body – if it should be allowed, what the syntax should be etc. With
      the "safety syntax", less is more as long as it gets accepted.

So what do you say people? Is it safe enough? One of the biggest arguments
I’ve heard against rushing in a class syntax now is that once its in we
have to keep supporting it. I say that this is small enough we won’t regret
it, and makes it possible to do a lot more in the future. If something more
substantial can be agreed on soon enough to make it into ES6, even better,
but maybe we can at least have a backup plan.

- Russ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120319/9cfb1f8b/attachment-0001.html>


More information about the es-discuss mailing list