Do Maximally Minimal classes carry their weight?

Herby Vojčík herby at
Sun Apr 1 02:58:10 PDT 2012

Russell Leggett wrote:
> When I started the "Safety Syntax" thread which let to the max-min
> proposal, I really did hope that we would still be able to slip some
> more features in for ES6, I just wanted to make sure we had *something*,
> even if it had to be max-min. I wanted to try to start with a useful
> baseline as fallback, so that we could continue to try to find consensus
> on more controversial features without fear of having no classes at all.
> I think min-max has been really successful, and at least we can say that
> there's nothing left to take out. If the last stragglers holding it back
> fear that it is *too* minimal, maybe now is the time to carefully try to
> find something to put it over the top for those in doubt.  Max-min has
> not reached a consensus, but it seems to at least gotten agreement that
> aside from some bikeshedding, it all belongs in classes i.e. there is
> nothing which needs to be removed/substantially changed.
> If we were to try to take the smallest baby step forward, I think it
> should be private names *inside* of a class. Private names seem like a
> pretty solid feature. There still seems to be some room on the syntax -
> private keyword for example, but overall seems pretty accepted. That
> makes it pretty solid ground, because adding it to classes would mostly
> be another piece of sugar to help bring the common parts
> together. Private names are a really great building block, but using
> private names in classes is going to be a really major use case for
> them, so I think it would be a pretty short leap to bring them together.
> As Domenic said, perhaps it would bring things over the top. There are a
> lot of new features in ES6. The <| operator (allowing extension/super),
> and private name objects are two features which are made more flexible
> by being stand-alone, but are perhaps a little low-level for the tastes
> of many mainstream developers. Max-min classes + class-scoped private
> names would be a way of tying in these new features, hitting the really
> common use case, but also formalizing a syntax for a pattern which has
> been around since the beginning. It is way of wrapping up the old and
> the new into a package which feels familiar, and should be easy to
> use/read/understand for new and old JS devs. I think it would be hard to
> say that proposal is "too little". The rest of the argument would still
> stand. It would still be fairly minimal and would hopefully still leave
> plenty of room for additional features.

Max-min classes were presented as the thing that does not prevent class 
evolution in "more object-initializer-like-way" (it is already 
unfriendly in making it object-initializer-syntactically bercause of 
comma-elision, but semantically it still can be) as well as other ways. 
Adding private names into class block may be the thing that stops this 
future friendliness.

It depends on one little detail. Does this code:

function make () {
   return new class {
     private x;
     constructor (x) { this. at x = "foo"; }
     xOf (o) { return o. at x; }

let obj = make();

print out "undefined" or "foo"?

If you agree that it prints out undefined, I will agree with private in 
classes. If you claim it should print out "foo", I'll say no to 
this-way-defined private inside class block.

Of course, this prints "foo" (the previous example is about 
independently created class expressions):

class FooHolder {
   private x;
   constructor (x) { this. at x = "foo"; }
   xOf (o) { return o. at x; }

let obj = new FooHolder;
console.log(new FooHolder().xOf(obj));

The bottom line is: there is already movement to have "private x" in the 
language, as the shortcut to _locally_* define x as Name.create(). If 
'private x' added to classes will follow this semantics (so it is 
deifferent for different invocations of class expression, but still the 
same for (the same) declared class (or for the instances of the same 
class expression), I will accept it; but I will raise my hand against if 
it would have different semantics.

> - Russ


* P.S.: I don't like it, I would rather see 'private x' as 'define 
static shared one over multiple invocations', but no one liked it that 
way, so I accepted 'shortcut to let' semantics; nevertheless, I want it 
to be everywhere consistently.

More information about the es-discuss mailing list