Vectors: https://github.com/soulwire/Coffee-Physics/blob/master/sourc...
Collision Detection: https://github.com/soulwire/Coffee-Physics/blob/master/sourc...
Vectors: https://github.com/soulwire/Coffee-Physics/blob/master/sourc...
Collision Detection: https://github.com/soulwire/Coffee-Physics/blob/master/sourc...
edit: hah, just saw who i replied to.
double edit: the renderer hierarchy he created is yet another good example of why I believe coffeescript needs interfaces...
> 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.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.
https://developers.google.com/closure/compiler/docs/js-for-c...
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?