Do Maximally Minimal classes carry their weight?

John J Barton johnjbarton at
Mon Apr 2 17:00:33 PDT 2012

Allen's original post on this thread offered two choices:
  1) extended object literals, (good building blocks).
  2) both, (because class gives 80% and thus they complement).
Erik and Tab are arguing for
  3) Min-max classes (we need 80%, not building blocks).
The current winner no one wants:
  4) do nothing.

Allen's large examples illustrates one point for me:  the class syntax
are not very big, compared to the other changes.

One important question for me: can the results of class syntax be used as
building blocks without the object-literal extensions? I mean: can the
built from class syntax be used meta-programming even if they are
not prefect tools for that purpose? Can the solution for 80% help with the
20% or at least no hinder?

I know this may be a difficult question to answer...


On Mon, Apr 2, 2012 at 2:39 PM, Erik Arvidsson <erik.arvidsson at>wrote:

> The main issue you will see if you do user studies on people trying to
> do OOP in JS is that the way to set up the prototype chain in ES3/5 is
> too hard. There is a reason why almost all JS libraries add ways to
> make this easier.
> With the "let C = B <| function() { ... }.prototype.{ ...
> }.constructor" pattern we are making the default pattern even harder
> to understand. Expecting people to get this is just too much to ask
> for.
> On Sat, Mar 31, 2012 at 10:40, Allen Wirfs-Brock <allen at>
> wrote:
> > What do you think?  Assuming that we will have some forms of enhanced
> object
> > literals in ES6, are max-min classes also worth the additional complexity
> > they add to the language?
> I think the code samples shows how much a dedicated class syntax can
> reduce the complexity, improves the readability and the intent of the
> code.
> Classes is a clear case of "Say what you mean!" whereas the
> let-triangle-function-prototype-monocle-mustache-constructor pattern
> is more like "I know how the internals work" which is hardly something
> we should be pushing for.
> --
> erik
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list