<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br></div>
    * has a declaration form that uses the class keyword and an<div class="im"><br>
      identifier to create the class<br>
</div></blockquote>
Why to rule out other possibilities (though I understand this one is the "least surprise" one)?<br></blockquote><div><br></div><div>I'm not sure I understand what you are asking, but I think you answered your own question. Remember - *safety syntax*. Minimal syntax without limiting future possibilities. We know that we will need "class Foo {". Let's just accept that as the base with future options later. And by later I mean "it can still be changed for ES6, just not for this discussion".</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">

A few things that are different from CoffeeScript:<br>
<br></div>
    * if there is no constructor, it doesn’t automatically pass<div class="im"><br>
      arguments up to the parent constructor. I think that would be nice<br>
      but more controversial.<br>
</div></blockquote>
A thing for discussion. Clear is clear, but you define the constructor anyway (you have to, it's the JS way). Maybe there should be extends* to say 'auto-generate forwarding, not clear one'.<br>
Though this is not the part of "safety" plan.<br></blockquote><div><br></div><div>We would have to decide what happens if they don't supply a constructor. I think we would need a default, and in my mind there are 3 possibilities:</div>
<div><ol><li>Empty constructor - does nothing.</li><li>Calls super with no args</li><li>Calls super as a pass through</li></ol><div>I'm fond of 3, but might be missing some controversial reason for one of the others. Personally, I would be willing to take any of them for the sake of classes.</div>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
    * to call super on a method you have to indicate the method super.move<br>
    * while not obvious in the example, I would say the class body should<br>
          o be its own construct, not just an object literal - this<br>
</blockquote>
-1. See more below.<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
            makes it easier to have methods without ,’s and be<br>
            future-proof for whatever we might want later<br>
</blockquote></div>
I have a lot of reasons (gut instinct, too, but also some though experiments on how things get powerful and concise things can be if classes automaticall had all the possibilities of (potientially revved-up) object literals [1]).<br>

So I need to see a really strong argument for abandoning the cause of "body of class should be the same as the body of object literal (with possible little numbers of changes)".<br></blockquote><div><br></div><div>
Ok, lets put it this way - my safety syntax only allows constructor + methods, with no commas in between. If commas after methods can be elided in object literal extensions then we're still on solid ground, it could go either way. What I would argue, though, is that we don't define the class body as equivalent to an object literal, there is still too much controversy there.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
So my -1 holds if you want to add anything that goes beyond the object-literal syntax, and I'd give -0.66 in case where you would restrict it too much.<br>
<br>
If you restrict it to only hold constructor and methods, it is still a compatible (though stripped) object-literal - you can have methods there (constructor is nothing special, just a method named 'constructor'; the magic of class keyword grants it [[Construct]] and .prototype created from {} block and according to object literal syntax you can have methods there without comma), so this would be -0.66.<br>
</blockquote><div><br></div><div>Well then I guess its a -0.66 from you, but remember this is the *safety syntax*! The battle can rage on later.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Without this restriction it would more or less be the same as proposal "3." in the thread unhappily named 'u' (my mail client probably did something wrong):<br>
<br>
3. 'class Name {...} [static {...}]' as a quasi-sugar for 'Name.prototype<br>
.{...} [.constructor.{...}] with Name body derived from constructor<br>
method in first {...}; always returning the constructor':<br>
(liberal use of <| for class declarations as well)<br>
<br>
private arr;<br>
<br>
class List {<br>
  constuctor (n) {<br>
    this.@arr = n === +n ? new Array(n) : [];<br>
  }<br>
  at (i) {<br>
    i = +i;<br>
    if (i>=0 && i<this.@arr.length) { return this.@arr[i]; }<br>
    else throw "Out of bounds: "+i;<br>
  }<br>
  size () { return this.@arr.length; }<br>
} static {<br>
  from (array) {<br>
    var r = new this();<br>
    r.@arr = array;<br>
    return r;<br>
  }<br>
};<br>
<br>
private writeArr, readOffset;<br>
<br>
List <| class Queue { // no problem if here is 'extends', but<br>
                      // I'd like it for function declaration, too, then<br>
                      // as in thread "extends with functions"<br>
  constructor () {<br>
    super();<br>
    this.@writeArr = [];<br>
    this.@readOffset = 0;<br>
  }<br>
  at (i) { /* needs redefinition */ }<br>
  size () {<br>
    return super.size() - this.@readOffset + this.@writeArr.length;<br>
  }<br>
  push (elements) {<br>
    return writeArr.push.apply(writeArr, elements);<br>
  }<br>
  shift () {<br>
    //reads from arr; shifts []->writeArr->arr if empty<br>
  }<br>
}<br>
<br>
// Queue inherits from, needs no static if it does not want something<br>
additional<br>
<br>
<br>
<br>
I silently assume here that extends creates, of course, double chain (constuctor inherits as well as prototype inherits, not just the latter)<br></blockquote><div><br></div><div>Correct</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
          o only allow a constructor function and methods - nothing<div class="im"><br>
            else. No public/private fields. No worrying about var x =<br>
</div></blockquote>
private can be done as above - out of class - it does not need as part of its syntax</blockquote><div><br></div><div>Absolutely</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
            {a:b} inside the class body – if it should be allowed, what<br>
            the syntax should be etc. With the "safety syntax", less is<br>
            more as long as it gets accepted.<br>
<br>
So what do you say people? Is it safe enough? One of the biggest<br>
arguments I’ve heard against rushing in a class syntax now is that once<br>
its in we have to keep supporting it. I say that this is small enough we<br>
won’t regret it, and makes it possible to do a lot more in the future.<br>
</blockquote></div>
It's too small. Whenever I want a shared field in prototype (other than method), I still must<br>
<br>
MyClass.prototype.{<br>
  sharedBar: 0,<br>
  sharedBaz: ""<br>
};<br>
<br>
This makes its inclusion a bit questionable (same for statics).<br></blockquote><div><br></div><div>If the alternative is *no* class syntax, you will have to do this anyway. Isn't this proposal still better than nothing?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Yes, we can go in little steps... but lots of them we already have (super expressions are already planned to be orthogonal to classes), and I think the next small step should be 'extends' for function declarations (which, unless <|, explicitly says "I am creating double chain here, in the spirit of 'classical' class inheritance; and if thing after extends is not constructor, I throw").</blockquote>
<div><br></div><div>What would you rather have?</div><div><br></div><div><div>    function Snake(name) extends Animal {</div><div>        super(name);</div><div>    }.prototype.{</div><div>        move(){</div><div>            alert("Slithering...");</div>
<div>            super.move(5);</div><div>        }</div><div>    }</div><div><br></div><div>or</div><div><br></div><div>    class Snake extends Animal {</div><div>        constructor(name){</div><div>            super(name);</div>
<div>        }</div><div><br></div><div>        move(){</div><div>            alert("Slithering...");</div><div>            super.move(5);</div><div>        }</div><div>    }</div></div><div><br></div><div>I know which one I would pick. At least as a safety syntax. The arguing can continue after that. I hope we get more than this minimum, but please, don't the indecision make the choice be "nothing".</div>
<div><br></div><div>- Russ</div></div>