<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>I can mostly dig it -- I've been trying to encourage minimal classes for quite some time now.</div><div><br></div><div>The part that I'm least happy about is that this doesn't allow for declarative private methods, because if we had the computed syntax like what we're adding to object literals, it would clash with hoisting:</div><div><br></div><div>    {</div><div>        let priv = new Name();</div><div>        class C {</div><div>            // oops, priv is still undefined!!</div><div>            [priv](x, y, z) {</div><div>                return x * y / z</div><div>            }</div><div>        }</div><div>    }</div><div><br></div><div>But I suppose the answer to that would eventually be better declarative syntax for `private`, as we've discussed but deferred for post-ES6 consideration.</div><div><br></div><div>I do think that class declarations should be hoisted, both in the sense of being in scope for the whole containing block (as with let and function) and in the sense of being initialized before the block begins executing (as with function).</div><div><br></div><div>My only syntactic quibble: `constructor` is so inconveniently long. I've argued in the past for `new` as special syntax in class bodies that indicates a constructor.</div><div><br></div><div>* short & sweet</div><div>* consistent with get/set shorthand</div><div>* already a keyword so it can be given special treatment</div><div>* doesn't have to actually correspond to a property called "new", so no extra magic properties on top of .constructor</div><div>* can still create a .constructor property as well</div><div><br></div><div>Dave</div><div><br></div><div>On Mar 19, 2012, at 1:03 PM, Russell Leggett wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><p class="p1">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.</p><p class="p2">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”.</p><p class="p2">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.</p><p class="p2">I would propose that the absolute minimal requirements would be:</p>
<ul class="ul1">
<li class="li3">has a declaration form that uses the <span class="s1">class</span> keyword and an identifier to create the class</li>
<li class="li3">has a body that can include both the constructor function, as well as any instance (prototype) methods – including getter and setter properties</li>
<li class="li3">can declare the class as a subclass of a another class (probably with the <span class="s1">extends</span> keyword)</li>
<li class="li3">super is available from any of the methods or constructor function</li>
</ul><p class="p2">The following is an example from the CoffeeScript website, and just converted to what seemed like a logical JS version:</p><p class="p4"><font face="'courier new', monospace">class Animal {</font></p><p class="p4"><font face="'courier new', monospace">    constructor(name){</font></p><p class="p4"><font face="'courier new', monospace">        <a href="http://this.name/">this.name</a> = name;</font></p><p class="p4"><font face="'courier new', monospace">    }</font></p><p class="p4"><font face="'courier new', monospace">    move(meters){</font></p><p class="p4"><font face="'courier new', monospace">        alert(<a href="http://this.name/">this.name</a> + " moved " + meters + "m.");</font></p><p class="p4"><font face="'courier new', monospace">    }</font></p><p class="p4"><font face="'courier new', monospace">}</font></p><p class="p5"><font face="'courier new', monospace"><br></font></p><p class="p4"><font face="'courier new', monospace">class Snake extends Animal {</font></p><p class="p4"><font face="'courier new', monospace">    constructor(name){</font></p><p class="p4"><font face="'courier new', monospace">        super(name);</font></p><p class="p4"><font face="'courier new', monospace">    }</font></p><p class="p4"><font face="'courier new', monospace">    move(){</font></p><p class="p4"><font face="'courier new', monospace">        alert("Slithering...");</font></p><p class="p4"><font face="'courier new', monospace">        super.move(5);</font></p><p class="p4"><font face="'courier new', monospace">    }</font></p><p class="p4"><font face="'courier new', monospace">}</font></p><p class="p5"><font face="'courier new', monospace"><br></font></p><p class="p4"><font face="'courier new', monospace">class Horse extends Animal {</font></p><p class="p4"><font face="'courier new', monospace">    constructor(name){</font></p><p class="p4"><font face="'courier new', monospace">        super(name);</font></p><p class="p4"><font face="'courier new', monospace">    }</font></p><p class="p4"><font face="'courier new', monospace">    move(){</font></p><p class="p4"><font face="'courier new', monospace">        alert("Galloping...");</font></p><p class="p4"><font face="'courier new', monospace">        super.move(45);</font></p><p class="p4"><font face="'courier new', monospace">    }</font></p><p class="p4"><font face="'courier new', monospace">}</font></p><p class="p5"><font face="'courier new', monospace"><br></font></p><p class="p4"><font face="'courier new', monospace">let sam = new Snake("Sammy the Python");</font></p><p class="p4"><font face="'courier new', monospace">let tom = new Horse("Tommy the Palomino");</font></p><p class="p2">A few things that are different from CoffeeScript:</p>
<ul class="ul1">
<li class="li3">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.</li>
<li class="li3">to call super on a method you have to indicate the method <span class="s1">super.move</span></li>
<li class="li3">while not obvious in the example, I would say the class body should</li>
<ul><li>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</li><li>only allow a constructor function and methods - nothing else. No public/private fields. No worrying about <span class="s1">var x = {a:b}</span> 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.</li>
</ul>
</ul><p class="p2">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.</p><p class="p2">- Russ</p>
_______________________________________________<br>es-discuss mailing list<br><a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a><br>https://mail.mozilla.org/listinfo/es-discuss<br></blockquote></div><br></body></html>