Minimalist Classes

Jeremy Ashkenas jashkenas at gmail.com
Wed Nov 2 06:26:08 PDT 2011


On Tue, Nov 1, 2011 at 8:18 PM, Brendan Eich <brendan at mozilla.com> wrote:

>
> Thanks, I did fork, and I made a Rich Corinthian Leather version, for the
> reasons given in the comments. In brief, I contend that over-minimizing
> will please no one: class haters still gonna hate, while class lovers used
> to batteries-and-leather-included will find the bare sheet metal poky and
> painful.
>
> Love it or hate it, I'm ok either way :-P. But I do crave intelligent
> responses.
>


When it comes to classes ... one man's minimalist is another man's baroque
;)

Since you've updated the Rich Corinthian Leather edition to return to
(extended) object literals as the RHS of the class definition -- we're now
effectively in agreement about the class proposal: the two flavors are the
same, if object literal extensions are added to JS.next, and the RHS is
restricted to be a literal instead of an expression, as super() calls might
necessitate. Groovy.

I think that if class bodies must be statically analyzable lists of
properties, then you can't go wrong with object literals. They're already
widely renowned syntax for such purposes -- so much so that languages like
Ruby are re-syntaxing their hashes to follow suit.

That said, we should take care to have the two things be fully consistent:
A class body should *be* an object literal, with no subtle differences in
the grammar leading to stumbling blocks down the line. If class bodies can
have:

class Runner {
  run() {
    ...
  }
  private quit() {
    ...
  }
  const speed: 10
}


... then an object literal should equally be able to have an identical body:

var runner = {
  run() {
    ...
  }
  private quit() {
    ...
  }
  const speed: 10
};


... as const properties and private methods on single objects are just as
useful and important as const properties and private methods on objects
that happen to be instances of a class.

Hopefully, unifying the two will have the side effect of making it easier
for TC39 to come to consensus on classes, if folks can agree to the general
"class name objectLiteral" scheme. You can do it (and desugar it) today
with ES3 object literals, and if ES6 object literals happen to have public,
const, and shorthand method syntax, ES6 classes will naturally have those
features as well.

(Full Disclosure: I'm still very opposed to const, private, and their
object-lockdown friends, but that should have no bearing on Brendan's
proposal.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111102/70dd32b9/attachment.html>


More information about the es-discuss mailing list