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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss -- Dr. Axel Rauschmayer [email protected] home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
