> 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.
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.
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.
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.
Does the coffee script compiler inline the addition calls? Does inlining actually do anything on v8 or the other javacript compilers?
I guess a better question for me to ask here is:
Is there any good in depth guide to the current javascript compilers so that library design decisions can be made, or are we basically restricted to reading the source code/ making a guess and checking with a profiler?
CoffeeScript doesn't inline the calls. V8 is pretty good but functions still have a discernible overhead. ClojureScript compiler macros are a pretty neat solution around this problem. Inlining can happen where you like yet you don't lose the generality of functions.
It’s clear and unambiguous, and does the right thing. Seems pretty reasonable to me to use the convention of never writing the word "this" in Coffeescript code, if you like. Not everyone in the world needs to have precisely the same style guide.
Vectors: https://github.com/soulwire/Coffee-Physics/blob/master/sourc...
Collision Detection: https://github.com/soulwire/Coffee-Physics/blob/master/sourc...