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.@arr = n === +n ? new Array(n) : [];
}.{
at (i) {
i = +i;
if (i>=0 && i<[email protected]) { return this.@arr[i]; }
else throw "Out of bounds: "+i;
}
size () { return [email protected]; }
}
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.@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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
