On Tue, Mar 20, 2012 at 1:08 PM, Rick Waldron <[email protected]>wrote:
> On Mon, Mar 19, 2012 at 4:03 PM, Russell Leggett < > [email protected]> 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; >> > Nevermind my previous message - somehow my eyes skimmed right past this. Sorry for the noise Rick > } >> >> 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"); >> > > Does |move| become an instance property method or a prototype property > method? > > > >> 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 >> >> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
