Class inheritance is not a common JavaScript design pattern. It's a hack, used by a minority of JavaScript developers, in a minority of projects.
The crux of the argument is that when you write CoffeeScript you think in JavaScript. But I absolutely never think about overriding a parent function in JavaScript. In CoffeeScript this is actively encouraged.
Like I said, as other ideas like await/defer become more mature (and are merged into mainline), we're going to see the design patterns diverge futher.
> But I absolutely never think about overriding a parent function
> in JavaScript. In CoffeeScript this is actively encouraged.
Unfortunately, if you never think about overriding a parent's implementation of a function in JavaScript -- all that means is that you willfully don't use prototypes. The famous "prototype chain", by which object-orientation in JavaScript is accomplished, is all about overriding versions of parent properties.
> Class inheritance is not a common JavaScript design pattern.
> It's a hack, used by a minority of JavaScript developers,
> in a minority of projects.
Nope, it's deeply ingrained in all object-oriented JavaScript that uses prototypes. What are the built-in String, Function, RegExp, Number, Array, and Object, if not classes?
There are a half a dozen different implementations of class inheritance in JavaScript. However no one writing a JS library is going to ask the consumer to extend one of their objects. This is what inheritance is all about. In Java you extend everything. Backbone.js is the only popular JS library I can think of which has their users use this pattern. It doesn't make since most of the time because:
1) The use of the pattern is not common in the js community.
2) If someone does use the pattern, they might be using a different implementation.
That you can override an Object's toString is not what we're talking about here jashkenas. We're talking about creating an Animal class and extending it with Horse.
> 1) The use of the pattern is not common in the js community.
The use of prototypes is ubiquitous in the JS community. There's no two ways about it.
Unfortunately, the avoidance of prototypes is also a common anti-pattern in the JS community, simply because JavaScript prototypes are so awkward, fragile and verbose. Doing the wrong thing with JS prototypes is easier than doing the right thing, which leads many developers to simply throw up their hands, and write code like this instead:
... which is terribly inefficient and wasteful of memory, and accomplishes nothing that a prototype couldn't do in a small fraction of the space and time.
Obviously the use of prototypes are ubiquitous in JavaScript. No one said otherwise. The use of class inheritance, as is common in other languages, like Java, C#, Python, and CoffeeScript is not common at all. Isn't that why you built it into CoffeeScript, because people were doing hacks to get super?
My point is that this is leading (and other features like await/defer will do this as well) to different design patterns. Such as Batman.js taking use of your extends keyword for consumers to implement their framework.
What you're calling "class inheritance" and what other folks call "the prototype chain" are one and the same thing. It's not built-in to CoffeeScript ... it's fundamentally built-in to JavaScript.
CoffeeScript is just making it three words:
A extends B
... instead of the usual JavaScript hoop jumping:
function ctor(){
this.constructor = A;
}
ctor.prototype = B.prototype;
A.prototype = new ctor;
Prototypal inheritance and class inheritance are not one and the same. How do I call super or base in JavaScript?
You know this, you had to add it to CoffeeScript. Do you not think the ability to call super functions leads to significantly different design patterns? If not, why did you add it? And why is EmcaScript.next probably going to have it?
Buddy, we're going around in circles here ... Yes, JavaScript lacks a way to easily call "super", but that doesn't mean that the concept doesn't exist.
Calling "super" means calling the immediate parent's version of the same function. CoffeeScript is just making it one word:
super
... instead of the usual JavaScript prototype hoop jumping:
We're going in circles because I'm talking about design patterns and you're talking about the ability to add features into JS that weren't in mind when it was designed; it can be a lisp if that's what you want. I'll gladly defer to you on what JS is ultimately capable of, it was never the point of my post. Rather my point is that the different syntax is leading to a divergence libraries and frameworks; Batman.js is a great example of a framework that, while you can consume it from JS, you probably wouldn't want to.
> However no one writing a JS library is going to ask the consumer to extend one of their objects.
Uh, if you're using the Closure libraries, you very likely are extending goog.Control or goog.Component. I don't know dojo, but from my brief perusal of the docs it looks like you do the same thing with dojo.declare. YUI seems to do the same with Widget. I'm not aware of a UI framework in JS that doesn't use inheritance from outside the library.
> Class inheritance is not a common JavaScript design pattern. It's a hack, used by a minority of JavaScript developers, in a minority of projects.
If you don’t like the way JavaScript’s prototypal inheritance works, take it up with Brendan Eich.
You are simply wrong about the commonness of using prototypes though. Nearly every big JavaScript project is organized around extending and creating prototypes, and making instances via the `new` keyword. It’s only a few zealots who militate against using that feature... and to the detriment of their followers, who end up with code that is slow and a memory hog.
The crux of the argument is that when you write CoffeeScript you think in JavaScript. But I absolutely never think about overriding a parent function in JavaScript. In CoffeeScript this is actively encouraged.
Like I said, as other ideas like await/defer become more mature (and are merged into mainline), we're going to see the design patterns diverge futher.