u

Brendan Eich brendan at mozilla.org
Thu Mar 15 12:12:51 PDT 2012


Herby Vojčík wrote:
> Brendan Eich wrote:
>> Definitely, but classes have bigger issues than private syntax, and have
>> for a while. Class-side inheritance, body syntax, whether there should
>> be any declarative public syntax, what nested classes mean, static or
>> 'class' members -- that's a partial list from memory.
>>
>> Minimal classes based on object literals could be done but seem too
>> minimal. As Waldemar suggested and Allen has worked to develop, they
>> tend to collapse into object literals (with smaller extensions).
>
> I am interested in this. Do you believe such classes, which are based 
> on object literal syntax are too minimal?
I'd have to see the proposal to say, but the general tendency observed 
by Waldemar is real: too minimal and there's no point. Too maximal and 
we can't agree. We need "Goldilocks classes" -- just the right 
temperature/amount.

> There is lots of possibilities what syntax to choose.

Yes, too many possibilities. That's a problem in itself.

> And, classes in JS are in fact just an object (a prototype) which can 
> be described (or extended) by a literal(-extension) (plus a 
> constructor, yes, but it is just a little decoration to it).

We don't even agree on prototype-first vs. constructor-first naming -- 
that is, whether classes in JS are "in fact" or in someone's opinion 
just a prototype (exemplar) object, or a constructor function (which as 
usual has a .prototype).

> I'd like to know what these solutions lack (why are they "too 
> minimal"). I will sketch some of them (they will use existing 
> features, like super expressions, <|, private name shortcut 
> declaration; some of the features more liberally).
>
> =====
>
> 1. 'class ...}' as a sugar for 'function ...}.prototype':
> (liberal use of <| for (sugared) function declarations as well)
>
> private arr;
>
> class List (n) {
>   this. at arr = n === +n ? new Array(n) : [];
> }.{
>   at (i) {
>     i = +i;
>     if (i>=0 && i<this. at arr.length) { return this. at arr[i]; }
>     else throw "Out of bounds: "+i;
>   }
>   size () { return this. at arr.length; }
> }

Comma elision in object literals is problematic, see past threads.

Here you .{ to extend the class prototype, which means class X(){} 
denotes a prototype not a constructor, but that's backward by analogy to 
function and it hurts the static/class-extension use-case.

No one has proposed class X(){} as a function-like form, but if someone 
did it would have to evaluate to the constructor. At that point, what is 
the purpose of 'class' instead of 'function'?

> List.{
>   from (array) {
>     var r = new this();
>     r. at arr = array;
>     return r;
>   }
> };

This looks like a class-side extension (from is a "static method", 
specifically an alternative constructor). So the class expression 
evaluates to the prototype, but the class name when used as an 
Identifier expression evaluates to the constructor? That's incoherent.

I'm out of time but I don't think shooting up a hodgepodge of 
proposal-parts, which don't appear to hang together, helps. Classes are 
not going to reach consensus this way. A gist focusing on one and only 
one approach would be better, and could be forked to show alternatives 
in a diffable way. We went through that exercise last year, Jeremy 
Ashkenas kicked it off. As usual with classes, even the least maximal 
proposal was too big and had a few controversial novelties (not found in 
CoffeeScript, e.g.).

/be


More information about the es-discuss mailing list