To me, it is amazing how much clearer maximally-minimal classes make this code.
The `<| function(){`, `}.prototype.{`, and `}.constructor.{` incantations in
[4] are almost completely opaque, as is the reason behind needing
`Function.prototype` as the lhs of `<|` for `AbstractClass`. They put the focus
entirely on the crazy mechanics involved in emulating “classes” in JavaScript’s
prototypal system, making you think about all the magic baked into constructor
functions, the `prototype` property, the `.prototype.constructor` property, and
how inheritance must be set up.
In contrast, I think [6] expresses the programmer intent exactly, at least so
far as maximally-minimal classes allow. (Which is to say, private names are
still done via arcane incantations.) And it relegates the `.{` operator to a
very understandable role: adding multiple properties at the same time.
Perhaps it is so much understandable because `.{` never appears “sandwiched,”
i.e. you never see `}.property.{`, only `something.{`. The former involves some
mental juggling as you recall what exactly was just closed with `}`, and what
magical semantics `property` has, and thus what the result of extending
`whateverWasJustClosed.magicalProperty` will be.
Another nice aspect is that it reduces use of the `<|` operator, which does
stuff that is nontrivial to correlate with a conventional notion of
subclassing. Adding maximally-minimal classes, with `extends`, would relegate
`<|` to the specialized use cases of people who know exactly what they’re
doing, e.g. those who like to work with exemplars. Which is, IMO, exactly where
it belongs.
In closing, I think these examples are an extremely strong argument for
maximally-minimal classes. They give ES6 programmers the means to express what
they mean, not what the language is contorting them into using. Without
maximally-minimal classes, ES6 just gives us the means to express class
patterns in an even-more-cryptic shorthand. With them, programmer intent shines
through.
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On
Behalf Of Allen Wirfs-Brock
Sent: Saturday, March 31, 2012 13:41
To: Allen Wirfs-Brock
Cc: es-discuss discussion
Subject: Do Maximally Minimal classes carry their weight?
At the recent TC39 meeting a couple people raised the concern that maximally
minimal class definitions [1] don't really do anything that isn't also possible
with enhanced object literals [2] and hence the additional complexity they add
to the language is undesirable. Only one of these alternatives should be in the
language and enhanced object literals are preferable because they are
compositional primitives that can be used to create a variety of higher level
abstractions.
The counter argument is that max-min class definitions and enhanced obj lits
support different use cases and that both are important. The class definitions
present a more complete abstraction that exposes the class model already
latent in the ES built-in objects. Even though max-min classes don't have all
possible class bells and whistles they are a good "80%" solution that will
likely to widely used and will facilitate code usage that crosses developer and
library boundaries. Enhanced object literals are independently useful as
compositional primitive and can be also be used to augment the capabilities of
max-min class definitions.
To make this debate more concrete, I've created new versions of my
Smalltalk-style collections class library [3] that use Max-min class
definitions. These new versions also use arrow functions and I've added a
version of the object literal based base-line that also uses arrow functions.
Comparing these versions are a good way see the differences (and similarities)
between the max-min classes and obj lit approaches to defining object
abstractions in ES6.
The new files are:
ST80collections-exp11.js [4]: This is the base line that uses the <| and .{}
pattern to defines "classes".
ST80collections-exp10.js [5]: Shows basic use of max-min classes declarations.
It uses Object.defineMethod to define class methods.
ST80collections-exp9.js [6]: Shows max-min classes declarations with .{}
used to define class methods and per instance properties.
Comparing either exp9 or exp10 to exp11 shows how max-min classes differ from
just using extended object literals.
Comparing exp9 to exp10 shows how .{} can pleasantly augment max-min class
definitions in support of uses cases that they do not directly support.
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?
Allen
[1]: http://wiki.ecmascript.org/doku.php?id=strawman:maximally_minimal_classes
[2]: http://wiki.ecmascript.org/doku.php?id=harmony:object_literals
[3]: https://github.com/allenwb/ESnext-experiments
[4]:
https://github.com/allenwb/ESnext-experiments/blob/master/ST80collections-exp11.js
[5]:
https://github.com/allenwb/ESnext-experiments/blob/master/ST80collections-exp10.js
[6]:
https://github.com/allenwb/ESnext-experiments/blob/master/ST80collections-exp9.js
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
