On Mon, Mar 19, 2012 at 1:03 PM, Russell Leggett
<russell.leggett at gmail.com>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?
>I love it. I would love it if we could be in the mode of "now we have a
class foundation, are there things we want to build on" and less in the
mode of "can I come to grips with the idea of having classes in JS at all?"
I like your proposal, and the analogy.
- bob
> 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>>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120320/5c07a693/attachment.html>