Do Maximally Minimal classes carry their weight?

Tab Atkins Jr. jackalmage at gmail.com
Mon Apr 2 15:16:26 PDT 2012


On Mon, Apr 2, 2012 at 2:39 PM, Erik Arvidsson <erik.arvidsson at gmail.com> 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 wirfs-brock.com> 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.

Strongly agreed.

I don't have any *particular* problem with the current ES3-style
classes, except that they're verbose to write and difficult to read.
Their structure doesn't *speak* to you when reading it; you have to
figure out for yourself what the right pattern is and how to recognize
it in code.

The maximal-minimal classes fix this by making the pattern simple to
write and obvious to read.  You see a "class" block, you know the
contents are defining methods on the prototype.  Simple!  Actually
writing it out is simpler, too, because you get to avoid all that
silly "foo.prototype.bar = function (...){...}" business in favor of a
simple "function bar(...){...}".  (I cannot tell you how many times
I've had to correct a syntax error when I wrote
"foo.prototype.bar(...){...}" instead...  I do this at least once per
project.)

Like Erik said, utilizing the new proto-of and dot-brace primitives to
make the verbosity somewhat smaller isn't much of a win.  You drop
some characters, but replace them with relatively opaque syntax,
rather than clear syntax.  It still requires you to learn the precise
details of the "correct" JS class model, which, though decently
designed imo, is still rather confusing.  Further, the dangling
".constructor" at the end is just nasty, since it's a *new*
requirement of this "one big expression" syntax, and wasn't necessary
when classes were just a big bag of statements.  There's little or no
net gain here.

Giving people easy, direct access to primitives is great.  It's a
requirement for real hacking in the language, and it often enables
interesting patterns that were never originally intended.  But that
doesn't invalidate the need for new high-level abstractions as well.
Maximal-minimal classes are a well-designed high-level abstraction
here.  They succinctly replace what was previously a hard-to-read
markup pattern.  The net gain is still *relatively* small right now,
but still noticeable, and they're friendly to future extensions that
magnify the gain over unadulterated base primitives.

~TJ


More information about the es-discuss mailing list