Do Maximally Minimal classes carry their weight?

Allen Wirfs-Brock allen at
Sun Apr 1 08:40:56 PDT 2012

On Mar 31, 2012, at 9:54 PM, 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.

Agreed, but we need to me really careful to not slip into controversy mode about additional features.  If that happens, it isn't clear that the recovery would be back to baseline max-min classes. It could go back to no class declarations at all.

> 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.

I think we need private outside of class declarations to cover all of the use cases (including those that aren't tied to classes).

I'd also be happy with private as a ClassElement that is lexically scoped to a ClassBody.

However, when we add private as a ClassElement we have crossed the line to having things other PropertyMethodDefinition in ClassBody. If this opens the flood gates for every over possible addition we will be back in the swamp.

We just need to be really careful to not get lost as we work toward final consensus on class definitions 


More information about the es-discuss mailing list