Finding a "safety syntax" for classes

Russell Leggett russell.leggett at gmail.com
Tue Mar 20 12:14:44 PDT 2012


On Tue, Mar 20, 2012 at 2:55 PM, David Herman <dherman at mozilla.com> wrote:

> I can mostly dig it -- I've been trying to encourage minimal classes for
> quite some time now.
>
> 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:
>
>     {
>         let priv = new Name();
>         class C {
>             // oops, priv is still undefined!!
>             [priv](x, y, z) {
>                 return x * y / z
>             }
>         }
>     }
>
> 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.
>

Yes, better private support would be nice. There is still time for
consensus on that that, but I still vote for this over nothing. Remember -
*safety syntax*! (I know, everyone will tire of me saying that)


>
> 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).
>

I agree, I think it would be counterintuitive otherwise. Hopefully this
will not hold it back. Unfortunately this is one issue which we can't
really put off because of the backwards compatibility monster.


>
> 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.
>
> * short & sweet
> * consistent with get/set shorthand
> * already a keyword so it can be given special treatment
> * doesn't have to actually correspond to a property called "new", so no
> extra magic properties on top of .constructor
> * can still create a .constructor property as well
>

Yes, I debated about this. In fact, I almost did go with new. Personally,
I'm fine with either. I think what swung me in favor of "constructor" was:

* other people seem to be happy with it, and that's what I'm shooting for
here
* CoffeeScript uses it. I don't really use CS, but it seemed short enough
for them.
* anyone making an additional .constructor is doing something bad, or maybe
I just can't think of a good reason.

Let's chalk this one down as a bike shedding issue that won't hold it back.

- Russ


>
> Dave
>
> On Mar 19, 2012, at 1:03 PM, Russell Leggett 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? 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/dd28fc5d/attachment-0001.html>


More information about the es-discuss mailing list