Brendan Eich wrote:
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.
Isn't this the reason why we should look over them and see which
direction is acceptable?
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 think this is already solved since in "new Foo" Foo is class (the
principle of "new Foo" expression) as well as constructor (by
implementation) at the same time.
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.
If it is problematic, it will be changed. Never mind. Let the classes
follow if they are based on that.
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.
It is not used as often as the prototype extension. Prototype extension
is the base of the class definition.
No one has proposed class X(){} as a function-like form, but if someone
I did, amongst others, in one of the threads.
did it would have to evaluate to the constructor. At that point, what is
the purpose of 'class' instead of 'function'?
Semantically readable shortcut. Same as 'private x' is for 'const x =
Name.create()'
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.
That is coherent with "new Foo" - 'Foo is the class' means 'new Foo
returns new instance'.
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
Sorry. I did not do that.
I posted the more-or-less complete proposals, by-example way.
They are thought of. They're not mere parts.
And others (there are three of them) are different - there isn't the
"incoherency" you mentioned in the next two.
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
Doesn't strike a chord with me.
I really feel handing more versions in and letting them to be compared
is good thing to do.
If you do not have time now, I'd be glad if you would be possible to
look over them and comment them later, not shun them after first
apparent error.
in a diffable way. We went through that exercise last year, Jeremy
Well, these are really different (maybe 2 and 3 may be diffed, but 1 is
different from them...).
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.).
There are minimal uses of class keyword that reuse object-literal. Since
there is demand for 'class', I'd summarized what minimal uses that blend
well with language but can help those that come from classful
environments as well. I don't think they have this 'too maximal to
swallow' property, neither of them.
The question is more of 'is it possible to have minimal (but still
useful) use of class in ES.next(.next)) or there is demand to use it
heavily?'. I am for lightweight use (or none - I can live without it,
but it helps).
/be
Herby
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
