On Mar 16, 2012, at 6:05 PM, Kevin Smith wrote:
> var Blah = BaseClass <| function(){}
> Blah.prototype.{
> a: function(){},
> b: function(){}
> }
>
> The point I'm trying to drive home is that the above is no better (worse, in
> fact) from a user experience standpoint, than what I have now. To be blunt,
> I would not use the above construction - my library's API is better.
>
Going back to David's post that originated the above code. It was comparing it
to:
> function Blah()
> Blah.prototype = Object.create(BaseClass.prototype);
> Blah.prototype.a = function() {};
> Blah.prototype.b = function() {};
which using my pattern would could actually be written like:
let Blah = BaseClass <| function() {
}.prototype.(
a() {},
b() {}
}.constructor.{};
(BTW, there are other pattern variations we have explored, some of which are
arguably better than this one...)
It is hard for me to see how this is worse than the the original code. Here
are ways that it is better:
It is one statement, not 4.
It is well delimited, it you need to move it somewhere else it is easy to
find the beginning and end.
It is an easily recognized pattern not just a sequence of assignment
expressions.
The definitional elements, the name, and the superclass are on the first line
It provides both instance and class side inheritance
Methods aren't enumerable, don't unexpectedly show up in for-in looops
Not shown: It provides a way to perform super construction introducing name
coupling (easer to refactor class hierarchy)
Not shown: Methods may to super invokes, again without introduce name coupling
Not shown: It provides a place for class-side properties to be defined"
It is more concise, with fewer noise words.
> But what I'm trying to understand is the need for classes.
>
> There is a school of thought that believes that it is always suboptimal to
> express encapsulation and reuse in Javascript in terms of "classical"
> classes. I do not subscribe to this belief. Sometimes (but not always)
> classes can be the right tool for the job.
>
> ES3/5 gives us a programming model that includes constructors and prototypes.
> It does not give us "classes". With constructors and prototypes, though, we
> can create classes. I argue that this "stack" should be maintained. A class
> syntax would be great, but whether we get it or not, classes should be an
> abstraction built on top of constructors and prototypes. We should not allow
> class concepts (like super-delegation) to bleed down into the realm of object
> literals.
First, "super delegation" is not a "class concept", rather it is a fundamental
concept of both inheritance or delegation based computational models. Look
that the self language. You will find that it has super
Next, the above pattern is doing exactly what you are asking for. It is a
pattern for defining and composing prototypes and constructors into to the
class model that is used for all of the built-in ES object abstractions. The
object literal extensions make this pattern more concise and expressive.
Allen_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
