[TrevorBurnham]

In some cases (e.g. "class Box extends Batman.Object"), the corresponding JS would be much more verbose and less immediately grok-able.

I think CoffeeScript is mainstream enough at this point that CoffeeScript-based documentation is a fine thing. Especially since, as they say at the top of the page, Batman.js "is written in CoffeeScript and its API is developed with CoffeeScript in mind."

[MatthewPhillips]

> In some cases (e.g. "class Box extends Batman.Object"), the corresponding JS would be much more verbose and less immediately grok-able.

True, but that just basically means that using JS with Batman.js is going to be a pain. In backbone.js you also extend their base classes, but you do it in a js-friendly way (var Widget = Backbone.Model.extend).

Not that there is anything wrong with a CS framework, but they should just say that it's a CS framework. The way CS compiles it's class inheritance to JS is not something I'd want to write raw.

[jashkenas]

For the record, the way that CoffeeScript does inheritance and the way that Backbone's "extend" does inheritance is almost literally exactly the same thing.

Both simply create an empty object to serve as the prototype (calling new without actually running your constructor), set up the prototype chain correctly, and stash a reference so that calling `super` is easier later on.

If "Child" and "Parent" are constructor functions (class objects), then the basic pattern is this:

    var ctor = function(){};
    ctor.prototype = Parent.prototype;
    Child.prototype = new ctor;
    Child.prototype.constructor = Child;
    

Fun.

[MatthewPhillips]

This is the way JS devs have been hacking inheritance for a long time. That's irrelevant though, we're not comparing CS to Backbone, we're comparing Batman.js to Backbone.

Backbone handles the messy inheritance code for you. Batman.js relies on CS for that, but a JS dev is going to have to write the inheritance code by hand. I posted the JS equivalent of their example in this thread, it's nasty.

[jashkenas]

It is indeed nasty ... and for that extra nastiness, above and beyond the inheritance pattern listed above, you get:

* A subclass that inherits the parent's implementation of the constructor function, unless overridden.

* A named function for your class object, without IE scope leaks.

* A way to call super that's as easy as `super()`.

* Inheritance of the parent's own properties (unfortunately via copying).

* ... which enables helpful metaprogramming within class bodies. For example, Batman's own `event` decorator:

    use: @event (times) ->
      return false unless ...