Complete Minimal Classes
On Fri, Apr 6, 2012 at 1:27 PM, Kevin Smith <khs4473 at gmail.com> wrote:
Looking at Allen's collection classes, it's clear that our maximally minimal classes aren't sufficient for describing a large subset of the classes we might want to create. As a general goal, I think that a complete class syntax should be able to express all of the external interface of the class, for all except a small set of edge cases.
A complete class syntax, yes. Maximally-minimal classes aren't attempting to be a complete class syntax. They're trying to be a maximally minimal class syntax, which is friendly to future extension to make it more complete. That way we can defer the debates about future functionality and syntax while still getting some work done now.
I believe the following features are missing:
- A way to add methods to the constructor.
- A way to add arbitrary properties to the constructor.
- A way to add arbitrary properties to the prototype.
I'd also like to add a fourth feature:
- The ability to separately define the [[Call]] and [[Construct]] behavior of the constructor.
I've created a couple of gists with a variant of our minimal classes which is intended to provide these features:
gist.github.com/2319957, gist.github.com/2322512
I've used "static" as a keyword. I know it's a misnomer - but it's not too bad as misnomers go. I've also left out private members and private names, as IMO they are an orthogonal concern.
Let me know what you think - and thanks for your time everyone!
I think all of this functionality is useful, but not strictly necessary right now, and we can add it in the future.
On Fri, Apr 6, 2012 at 4:31 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
On Fri, Apr 6, 2012 at 1:27 PM, Kevin Smith <khs4473 at gmail.com> wrote:
Looking at Allen's collection classes, it's clear that our maximally minimal classes aren't sufficient for describing a large subset of the classes we might want to create. As a general goal, I think that a complete class syntax should be able to express all of the external interface of the class, for all except a small set of edge cases.
A complete class syntax, yes. Maximally-minimal classes aren't attempting to be a complete class syntax. They're trying to be a maximally minimal class syntax, which is friendly to future extension to make it more complete. That way we can defer the debates about future functionality and syntax while still getting some work done now.
As Tab says, you won't really find anyone here that thinks Max-Min isn't missing features. The point is that there have been dozens of full-featured proposals just like yours which haven't come to consensus. Max-min was an attempt to take every controversial feature out while still remaining useful and leaving the door open for the future. It seems to me that so far this is the closest to consensus. Trying to go the other direction is probably just going in circles. Maybe I'm wrong. I know that the biggest thing holding it back is that for a couple holdouts it is too minimal and possibly competes with some of the work being done for object literal extensions. Personally, I think that if anything should be done to fix Max-min it should be in the private name area.
+1.
With a class expression and .{, you can also conceivably have constructor properties:
var MyClass = class extends Foo { ... ) . { /* constructor properties go here */ }
I don’t use constructor properties often, so I think it’s OK not to have them in MM classes (with the option of adding them e.g. in ES.next.next).
A complete class syntax, yes. Maximally-minimal classes aren't attempting to be a complete class syntax.
Then they are half-baked and non ready for inclusion in a mature language. This conclusion is unavoidable.
On Fri, Apr 6, 2012 at 4:18 PM, Kevin Smith <khs4473 at gmail.com> wrote:
A complete class syntax, yes. Maximally-minimal classes aren't attempting to be a complete class syntax.
Then they are half-baked and non ready for inclusion in a mature language. This conclusion is unavoidable.
No, they solve a simple problem and are friendly to future extension.
(The problem being that the current class pattern is verbose to type and hard to intuit when reading.)
Again, the entire point of maximally-minimal classes was to be as simple as possible while still providing something useful (which they succeeded at), and to remain friendly to becoming more complicated in the future (also succeeded!).
Again, the entire point of maximally-minimal classes was to be as simple as possible while still providing something useful (which they succeeded at), and to remain friendly to becoming more complicated in the future (also succeeded!).
Even if maximally minimal classes could make it into ES6, why not try to make a complete syntax (and model) now? We've come this far...
Do you disagree with any of the four points that I made?
On Fri, Apr 6, 2012 at 7:34 PM, Kevin Smith <khs4473 at gmail.com> wrote:
Again, the entire point of maximally-minimal classes was to be as
simple as possible while still providing something useful (which they succeeded at), and to remain friendly to becoming more complicated in the future (also succeeded!).
Even if maximally minimal classes could make it into ES6, why not try to make a complete syntax (and model) now? We've come this far...
Do you disagree with any of the four points that I made?
What you're missing is the history. Do you think that your proposal is so much more compelling than the several which have come before? Don't get me wrong - I don't think its bad. I'm not trying to belittle it, I'm trying to get you to see why Max-min is more than something half-baked. What's wrong with this one harmony:classes or this
one strawman:classes_as_sugar or this
one gist.github.com/1332193? You probably have your reasons, and
other people have the same type of problems with yours. I think the biggest problem with getting classes into JS is because it is beyond the point where a single visionary language designer can just step in and make the decision. Classes are just one of those things hairy enough that consensus is just so challenging.
The question we should be asking is, "Assuming we went with max-min or something like it, why would future decisions be any easier than they are now." I say that if something like max-min is the only way to get classes into the hands of users, that is an important accomplishment. JS is taking the IMHO smart approach of paving the cowpaths. Max-min certainly paves a well worn and important cowpath instead of treading too far into new territory. After its paved, and we get other things in the mix like private names, and turn people loose, new cowpaths will form that build from what we've got. Then we'll have a clearer picture of the best route to take next. If we keep going around looking for a complete solution, nothing will happen, now cowpath will be paved, and we really won't be closer for ES7. That is what I fear the most.
What you're missing is the history.
Russell, that's not fair. I've been listening for quite a while and I've combed through the archives. I've poured over each of the proposals that you've mentioned. You're assuming that I'm some kind of newbie because I dissent?
I knew this post might be unpopular, but I'm trying to help and I have something to say. Don't shut me down just because I'm not stepping in line.
Back to the point:
Forget about syntax details - I posted a possible syntax, but it could be anything. Do you disagree that at least the first three items in my original post should be in any complete class syntax?
On Fri, Apr 6, 2012 at 9:38 PM, Kevin Smith <khs4473 at gmail.com> wrote:
What you're missing is the history.
Russell, that's not fair. I've been listening for quite a while and I've combed through the archives. I've poured over each of the proposals that you've mentioned. You're assuming that I'm some kind of newbie because I dissent?
I knew this post might be unpopular, but I'm trying to help and I have something to say. Don't shut me down just because I'm not stepping in line.
I'm not assuming you're a newbie. Heck, I consider myself a newbie. Perhaps I'm just jaded. Two weeks ago, I had hope that max-min would get us something. Now I'm feeling less hopeful. New class proposals going in the other direction feels like going in the circles. We need to address the consensus gap more directly.
Regarding your proposal specifically, this is what I see:
Arbitrary prototype properties is surely to draw fire. It can be a foot-gun and might conflict with instance properties in the future. Adding support for statics is probably less controversial. In truth, I think its the only real difference between max-min and David Herman's min classes. However, that means if we take out arbitrary prototype properties, we're back to a proposal which also hasn't reached consensus. As for your fourth, most controversial point, separating call and constructor would diverge from the existing pattern. Number() and new Number() always call the same function. My opinion on whether or not its a good idea doesn't even factor in. I want classes. I don't see this feature being even remotely possible to consensus. If we get consensus on something, I would love to debate more controversial features.
I'm not trying to shut you down. I just really want classes to happen, even if in the most minimal form. I apologize if I seem dismissive, I just don't see it as being the most productive way of getting there.
Russell Leggett wrote:
However, that means if we take out arbitrary prototype properties, we're back to a proposal which also hasn't reached consensus.
No proposal has. It's possible we'll get there either way, what is in max-min or in Kevin's gists (not far off). Neither addresses the sticking point that I heard in committee.
As for your fourth, most controversial point, separating call and constructor would diverge from the existing pattern. Number() and new Number() always call the same function.
That's one pattern. The other is Date() vs. new Date(), Object(otherObj) vs. new Object(otherObj), and kindred warthogs.
I like Kevin's gist and want a private declaration too, both on its own (block-scoped so private foo is const foo = new Name('foo')) and as a special form in a class body, for body-scoped (fresh Name per class expression or declaration evaluation) class-private instance variable naming.
None of this will kill us, max-min is just the smallest step, and one complaint has been about "doing too little". But the bigger complaint I saw was the one Waldemar raised (and has raised often): inability to declare something like
sealed class Rect extends Shape { new(x, y, w, h) { super(); // initialize x, y, w, h instance variables } ... }
where, whatever the instance-property declaration and initialization syntax, instance properties cannot be used before initialized, and the instance is sealed by end of the new() method, and super() cannot add expandos. Therefore, users of new Rect(...) can be sure they have an object with only whatever Shape declared, plus x, y, w, h and any prototype methods -- and no other properties. You get a runtime error if you typo a property name.
Whether 'sealed' would be required or not, depending on what we do in ES6 and later, I put it in to distinguish this Rect declaration from typical examples we've seen that do not care about sealing or throwing on typos.
Clearly some careful barrier specification would be required to satisfy the no-use-before-init, no-expandos, typos-on-unmapped(by-prototypes-if-not-instance)-properties goals.
The argument against max-min or other proposals that do not achieve these goals goes like this: supporting sealed classes later will make them less used or not used, when this is the sweet spot and justification for classes over extended object literals. Therefore doing only unsealed classes of the max-min or similar (per above) kind in ES6 does too little and makes a permanent attractive nuisance.
This is in addition to any future hostility (hard to prove there isn't any, and I think Waldemar backed down on that objection). This is the obstacle that I see. I think Allen's followup to the meeting notes captures it, but I wanted to emphasize the sealed, no-expandos, ivar-typo-checking goals.
I hope Waldemar will correct me if I've misunderstood.
I'm not favoring anything by writing this, just trying to capture the constraints we face in trying to find consensus.
I'm not assuming you're a newbie. Heck, I consider myself a newbie. Perhaps I'm just jaded. Two weeks ago, I had hope that max-min would get us something. Now I'm feeling less hopeful.
No way - we're gonna get classes in. : )
Arbitrary prototype properties is surely to draw fire. It can be a foot-gun and might conflict with instance properties in the future.
Foot gun: yes. I've shot myself in the foot with it. But I think it can be addressed in a way that's footgun-proof. We're going to need arbitrary prototype properties at some point. I can elaborate on why I think so later. As for conflicting with instance initializers, our footgun-proof syntax wouldn't need to conflict with that.
As for your fourth, most controversial point, separating call and
constructor would diverge from the existing pattern. Number() and new Number() always call the same function.
They don't always do the same thing though - check out Date (15.9.2 & 15.9.3).
Otherwise, we have to do something painful like:
if (this instanceof MyClass)
// construct it
else
return new MyClass(...args);
I'm not trying to shut you down. I just really want classes to happen, even if in the most minimal form. I apologize if I seem dismissive, I just don't see it as being the most productive way of getting there.
No problem! The "half-baked" thing was a little over the top, I admit. : )
Kevin Smith wrote:
Arbitrary prototype properties is surely to draw fire. It can be a foot-gun and might conflict with instance properties in the future.Foot gun: yes. I've shot myself in the foot with it. But I think it can be addressed in a way that's footgun-proof. We're going to need arbitrary prototype properties at some point.
Why? I mean, what built-in in ECMA-262 or a DOM spec needs non-method data properties? Methods and accessors, yes. Constants go on the constructor. I'm probably forgetting some bogus Java-like WebIDL binding rule here...
Otherwise, we have to do something painful like:
if (this instanceof MyClass) // construct it else return new MyClass(...args);
Even here, you can be spoofed by calling the constructor on an already-constructed instance. It's hard to tell 'new' from invocation by checking facts about |this|.
Brendan Eich wrote:
I like Kevin's gist and want a private declaration too, both on its own (block-scoped so private foo is const foo = new Name('foo')) and as a special form in a class body, for body-scoped (fresh Name per class expression or declaration evaluation) class-private instance variable naming.
I don't think private in class-body is in any way special. As I see it, it's the exactly same 'private foo' which declares foo locally visible in the {} block with value of Name.create().
Seeing the other way, if you imagine 'private x' possible in object initializer, so you can write: let singletonCounter = { private c, @c: 0, inc() { ++this. at c; }, val() { return this. at c; } };
then 'private x' in class body is just straightforward syntactic mapping of this 'private x' into class-body syntax.
None of this will kill us, max-min is just the smallest step, and one complaint has been about "doing too little". But the bigger complaint I saw was the one Waldemar raised (and has raised often): inability to declare something like
sealed class Rect extends Shape { new(x, y, w, h) { super(); // initialize x, y, w, h instance variables } ... }
where, whatever the instance-property declaration and initialization syntax, instance properties cannot be used before initialized, and the instance is sealed by end of the new() method, and super() cannot add expandos. Therefore, users of new Rect(...) can be sure they have an object with only whatever Shape declared, plus x, y, w, h and any prototype methods -- and no other properties. You get a runtime error if you typo a property name.
Whether 'sealed' would be required or not, depending on what we do in ES6 and later, I put it in to distinguish this Rect declaration from typical examples we've seen that do not care about sealing or throwing on typos.
Clearly some careful barrier specification would be required to satisfy the no-use-before-init, no-expandos, typos-on-unmapped(by-prototypes-if-not-instance)-properties goals.
The argument against max-min or other proposals that do not achieve these goals goes like this: supporting sealed classes later will make them less used or not used, when this is the sweet spot and justification for classes over extended object literals. Therefore doing only unsealed classes of the max-min or similar (per above) kind in ES6 does too little and makes a permanent attractive nuisance.
This is in addition to any future hostility (hard to prove there isn't any, and I think Waldemar backed down on that objection). This is the obstacle that I see. I think Allen's followup to the meeting notes captures it, but I wanted to emphasize the sealed, no-expandos, ivar-typo-checking goals.
Interesting. Thanks for information.
Kevin Smith wrote:
Arbitrary prototype properties is surely to draw fire. It can be a foot-gun and might conflict with instance properties in the future.Foot gun: yes. I've shot myself in the foot with it. But I think it can be addressed in a way that's footgun-proof. We're going to need
Nothing of real value (and power) can be footgun-proof. I value expressivity and power in a programming language a lot over footgun-proofness (no more Java, thanks).
Why? I mean, what built-in in ECMA-262 or a DOM spec needs non-method data properties? Methods and accessors, yes. Constants go on the constructor. I'm probably forgetting some bogus Java-like WebIDL binding rule here...
The Event constants (AT_TARGET, etc.) are defined on the Event prototype (as well as on the constructor). Another use case, mentioned by Dave, would be adding generic methods defined elsewhere to the prototype. Or if you wanted to add methods using a template function:
prototype {
methodA: createMethod("a"),
methodB: createMethod("b")
}
Even here, you can be spoofed by calling the constructor on an
already-constructed instance. It's hard to tell 'new' from invocation by checking facts about |this|.
Right - which is why it would be nice to be able to specify the behaviors separately.
Kevin Smith wrote:
The Event constants (AT_TARGET, etc.) are defined on the Event prototype (as well as on the constructor).
Java hold-over, I think (class statics are available on instances, IIRC).
Another use case, mentioned by Dave, would be adding generic methods defined elsewhere to the prototype.
This is a better one. Your braced sub-body would work and perhaps be enough syn-tax to keep the footgun aimed at the right target, or on-safe.
I could still defer it and live, in the spirit of getting enough of classes through and building on it based on cow movement later. But I'm with you in not wanting to do too little, or (Waldemar's concern) steer the herd in a direction we will foreseeably regret (but I don't have Waldemar's foresight -- not sure I believe in that in this domain).
Right - which is why it would be nice to be able to specify the behaviors separately.
I like your new(){}/static(){} idea at a glance. Need to ruminate (moo!) on it at length.
I have actually looked at the links (I confess I did not want to browse though another way to ruin (nearly a) consensus on max-min), and I must admit I like it.
Only things that bothers me a bit (except the inconsistent new keyword) is the potential ambiguity - I can add method to body, but (since I presume prototype and static block and fully-blown object initializers (if not, I take it back and I do not like it)) also to prototype / static block, as I see fit.
So I can write (comments snipped):
class Monster {
new(name, health) {
this.name = name;
this[pHealth] = health;
}
prototype { attack(target) { log('The monster attacks ' + target); },
get isAlive() {
return this[pHealth] > 0;
},
set health(value) {
if (value < 0) {
throw new Error('Health must be non-negative.')
}
this[pHealth] = value
},
numAttacks: 0,
attackMessage: 'The monster hits you!'
}
static { numMonsters() { return this.allMonsters.length; },
allMonsters: []
} }
if I see it as a layout I like more.
And so there can be two kinds of writing down the class and reader will need to switch PoV if reading one from the opposite "school".
Otherwise, nice (again, if prototype/static are full-blown object initialziers).
I like your new(){}/static(){} idea at a glance. Need to ruminate (moo!) on it at length.
Some details:
- Clearly super() would have to call the [[Construct]] behavior: new() {}.
- If there were a different number of formal parameters for the two, what would MyClass.length be?
- What would MyClass.toString() return?
I haven't been able to think of any big problems yet...
Thanks for taking a look!
Only things that bothers me a bit (except the inconsistent new keyword) is the potential ambiguity - I can add method to body, but (since I presume prototype and static block and fully-blown object initializers (if not, I take it back and I do not like it)) also to prototype / static block, as I see fit.
The idea is that "prototype {}" blocks and "static {}" blocks would work just like object extension literals, and any duplicate property names would be dealt with in the same way.
Kevin Smith wrote:
I like your new(){}/static(){} idea at a glance. Need to ruminate (moo!) on it at length.
I can't give you a use case (it's just a felling of being a good design thing), but I would like the classes be higher-level construct based on low-level ones. If new()/static() gets in, it defines its own exclusive semantics not possible to do by plain constructor function.
Maybe there should be possibility to define split-body plain constuctor function, too (with semantics identical to class (or vice-versa)).
Bikeshedding:
function new Ctr (a) { constructor body } static (a,b) { static body }
(with static required if new form is used; maybe "static throw" or "static undefined" as shortcuts if one wants static behaviour to throw (system-defined error with "[[Call]] behaviour not supported, this is pure constuctor" meaning) or wants to have it empty; in that case they should be there in class as well).
What does class do if you add new(){} but not static(){}? I presume it [[Call]]s new(){} body...
I can't give you a use case (it's just a felling of being a good design thing), but I would like the classes be higher-level construct based on low-level ones. If new()/static() gets in, it defines its own exclusive semantics not possible to do by plain constructor
I agree in general, but as you say, differentiating between [[Call]] and [[Construct]] is not really possible from within a called function (AFAIK). There is a functionality gap here, and I believe that classes are the right place to fill in that gap.
What does class do if you add new(){} but not static(){}? I presume it
[[Call]]s new(){} body...
My intuition says that if you did not specify a "static() {}", then MyClass(...) and new MyClass(...) would be equivalent (ala the more common pattern in the Chapter 15 "classes").
But isn’t a clear separation of responsibility better?
Want a constructor => use a class declaration.
Want a callable => use an arrow function.
I always disliked that some functions in ECMAScript 5 can be invoked as either a function or a constructor. What would you want an entity Foo for that can be invoked in two ways? E.g.: new Foo(...) Foo(...)
Axel
I always disliked that some functions in ECMAScript 5 can be invoked as either a function or a constructor. What would you want an entity Foo for that can be invoked in two ways? E.g.: new Foo(...) Foo(...)
Maybe Brendan can answer that one? : )
Seriously, though, it's a fair question. My first response is that since the Chapter 15 "classes" exhibit this behavior, we should be able to fully express it in a class syntax.
But beyond that, how should we deal with this situation? We could make classes not implement [[Call]], but that would mean we'd have functions that didn't implement [[Call]], which is (AFAIK) truly novel and perhaps a little bizarre. I don't see that happening, but I could be wrong.
So if [[Call]]/[[Construct]] duality is a fact, how should we deal with it?
-
Ignore the possibility of the constructor being [[Call]]ed. This is the typical response, because it's the easiest. It's also the most error-prone.
-
Use a best-effort approximation to detect a [[Call]] as in: joyent/node/blob/master/lib/buffer.js#L211-213
-
Separate the two behaviors into separate bodies, with a reasonable default for the [[Call]] operation.
I think (3) makes the most sense. What do you think?
Kevin Smith wrote:
I always disliked that some functions in ECMAScript 5 can be invoked as either a function or a constructor. What would you want an entity Foo for that can be invoked in two ways? E.g.: new Foo(...) Foo(...)
My answer to this is probably a little lame and self-referencing, but "this is the JS model". It has its pros - minimal, simple, allows interesting composition of things. And of course it has cons. I'd not change it, but embrace it.
Maybe Brendan can answer that one? : )
Seriously, though, it's a fair question. My first response is that since the Chapter 15 "classes" exhibit this behavior, we should be able to fully express it in a class syntax.
But beyond that, how should we deal with this situation? We could make classes not implement [[Call]], but that would mean we'd have functions that didn't implement [[Call]], which is (AFAIK) truly novel and perhaps a little bizarre. I don't see that happening, but I could be wrong.
So if [[Call]]/[[Construct]] duality is a fact, how should we deal with it?
Ignore the possibility of the constructor being [[Call]]ed. This is the typical response, because it's the easiest. It's also the most error-prone.
Use a best-effort approximation to detect a [[Call]] as in: joyent/node/blob/master/lib/buffer.js#L211-213
Separate the two behaviors into separate bodies, with a reasonable default for the [[Call]] operation.
I think (3) makes the most sense. What do you think?
I am for (3), but there are three reasonable defaults imo:
- call the [[Construct]] body as a function
- do nothing
- throw an early error
and as I outlined, there probably should be ways to select from these default (e.g. static this / static undefined / static throw).
I think separating [[Call]] and [[Construct]] to different bodies might be a good idea. But to preserve flexibility, I also think that if you do
MyClass.call(Object.create(MyClass.prototype));
it should call the [[Construct]]. i.e. if it should use [[Construct]] when 'this' is an instance of the class (inherits from it's prototype).
I often call functions that are supposed to be constructors on completely different objects that maybe inherit from that function or maybe not. This would open up the door for making it up to the class whether it works without the 'new' keyword, e.g.
class MyClass { construct (stuff, args...) { // Stuff },
call () { return MyClass.apply(Object.create(MyClass.prototype), arguments); } }
// Both do the same thing new MyClass(); MyClass();
MyClass.call(Object.create(MyClass.prototype));
it should call the [[Construct]]. i.e. if it should use [[Construct]] when 'this' is an instance of the class (inherits from it's prototype).
Of course, the above is equivalent to just "new MyClass(...)" (I think), but I see your point. It may be enough to sink the idea. Have to think about it...
On Apr 7, 2012, at 1:17 PM, Herby Vojčík wrote:
I have actually looked at the links (I confess I did not want to browse though another way to ruin (nearly a) consensus on max-min), and I must admit I like it.
My reaction to Kevin's initial post was much the same as Herby's. I'm just not interested in looking at new more comprehensive class proposals if we can't first get agreement on the level of functionally that is in the max-min classes proposal (and there are still points of disagreement on the details of that functionality). The agreement we needed is that :
- A max-min proposal will the common foundation for any other future "class" features (whether in ES6 or in future editions)
- A max-min by it self would be a worthwhile addition to ES
If we can agree on this then we can make progress. Any enhancement discussion prior to such agreement just makes achieving consunsus on these points more difficult.
We have already found that we are unable to find consensus starting with more complex proposal so I have very little interest in exploring them at this point in time.
Agreeing to Min-max in ES6 wouldn't shut the door to additional class features in ES6. It would rather open a door that for now seems firmly stuck.
Looking at Allen's collection classes, it's clear that our maximally minimal classes aren't sufficient for describing a large subset of the classes we might want to create. As a general goal, I think that a complete class syntax should be able to express all of the external interface of the class, for all except a small set of edge cases. I believe the following features are missing:
I'd also like to add a fourth feature:
I've created a couple of gists with a variant of our minimal classes which is intended to provide these features:
gist.github.com/2319957, gist.github.com/2322512
I've used "static" as a keyword. I know it's a misnomer - but it's not too bad as misnomers go. I've also left out private members and private names, as IMO they are an orthogonal concern.
Let me know what you think - and thanks for your time everyone!