Finding a "safety syntax" for classes

Rick Waldron waldron.rick at gmail.com
Tue Mar 20 10:10:08 PDT 2012


On Tue, Mar 20, 2012 at 1:08 PM, Rick Waldron <waldron.rick at gmail.com>wrote:

> On Mon, Mar 19, 2012 at 4: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;
>>
>
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
>> 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/5dadf326/attachment-0001.html>


More information about the es-discuss mailing list