Minimalist (why) classes ?

Brendan Eich brendan at
Mon Nov 14 15:29:17 PST 2011

On Nov 14, 2011, at 3:16 PM, John J Barton wrote:

> I'm not suggesting such an API. In fact I am suggesting that such an
> API is not always possible. If the syntax is
>   class D : B { pList }
> and requires that B be an identifier and pList list of properties,
> then the API would have to have restrictions on the arguments that I
> don't think we have a way to express.


BTW, no one proposes that B be an identiifer (which is a kind of expression). Static languages constrain B to be not only an identifier, but one declared previously as a class. We're not doing that. AFAIK all class proposals allow a general expression (probably AssignmenExpression in the grammar, to avoid comma problems) for B.

> I am not arguing what we should or must have APIs for all new syntax.
> I'm not arguing anything about new syntax. You've already decided not
> to listen to anyone like me when it comes to new syntax, and I've
> already agreed that is a good decision.

I don't remember it that way, but ok.

> The only reason I brought up class syntax was illustrate that class
> syntax can force constraints on the inputs to the inheritance that
> functions cannot do.

Good, ok. It sounded like the opposite, honest!

> And BTW these constraints may well be the most important advantage of
> class syntax. These constraints prevent you from pointing the gun at
> yourself.


>> Nope, because there's no copy in the class D extend B { <P> } syntax. There is no expression evaluated to compute P as an object, and then reflection on that object to define properties of D's new prototype object. Instead the syntax of P as a class body can be specified entirely without resort to any kind of copy-ish copying.
> Well I did not write
>   class D extend B { <P> }
> specifically because that would imply that the RHS is a literal.

No, braces don't mean only and ever "literal". Function bodies are not literals, i.e. literal values. They're code bodies. Class bodies could be something else again, and are in Dave's minimial_classes proposal.

But I take your point -- I was trying to be meta not concrete with the <> brackets. Moving along...

> If it
> is a literal, then you don't have to copy, which is exactly my point:
> the heart of "the problem" is the copy demanded by functions but not
> by new syntax.

Great, we agree. Why did I think you were arguing the other side? Hrm.

> I want to survey the existing practice and create a set of tests
> illustrating the various choices and their trade offs. I don't expect
> any choice will satisfy everyone.

A broad survey would be wonderful. Your taxonomy of sharing/copying is good to go. Whether we find one true way or several good approaches, this seeems worth doing. We don't have to standardize anything now (we should not rush) but analyzing the paths can only help (even if some are "bad paths").


More information about the es-discuss mailing list