[jashkenas]

    > the renderer hierarchy he created is yet another good example 
    > of why I believe coffeescript needs interfaces...

What exactly are you thinking of here? Because JS is as flexible as you can be in terms of duck-typing and calling any function with any number of arguments -- I don't see what having an explicit "interface" construct would gain you.

[functionform]

Compiler safety for the design. Implement a base class, and force implementation for sub classes. I know that CS philosophically is about keeping JS's openness, but I feel it would be a time saving convenience if the compiler told me I was missing a method.

[munificent]

If you want a language that compiles to JS and has more compile-time checking, I'd encourage you to check out Dart. It's not everyone's cup of tea, but if you don't mind semicolons and curly braces, it gives you a pretty decent amount of compile time checking while still generating nice JS.

[jashkenas]

Ah yes -- this would be very against the open/dynamic spirit of CS and JS -- and for that reason, we'd never add it. Many valid uses of subtypes don't need to implement every method defined by a parent type (or interface) in order to be used correctly.

For example, a rich "collection" interface that has some helper functions for key:value hash-like collections, but that a more array- or set-like subtype doesn't have to implement.

If you forget to implement a method that you later try to use, you'll find out when you try to use it. Such is the nature of the beast.

[insin]

You could use Closure Compiler for that instead:

https://developers.google.com/closure/compiler/docs/js-for-c...