Finding a "safety syntax" for classes

Axel Rauschmayer axel at rauschma.de
Wed Mar 21 00:57:13 PDT 2012


I’d still consider support for private name objects and for static minimal, but indeed would not add anything else:

https://gist.github.com/1336846



On Mar 19, 2012, at 21:03 , Russell Leggett wrote:

> 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
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-- 
Dr. Axel Rauschmayer
axel at rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120321/93f69dcd/attachment-0001.html>


More information about the es-discuss mailing list