> Thanks for the comment. I have added big red (orange ...) boxes to let the user know that it is considered bad practice Guys, don't spread ignorance. Implem

> Thanks for the comment. I have added big red (orange ...) boxes to let the user know that it is considered bad practice Guys, don't spread ignorance. Implementation details aren't essential, therefore a "bad practice" in this respect is just an ignorance. Once again: the difference between classical and prototype-based (delegation-based in this case) inheritance is _ideological_. In first case (classical) we have systematized (classified) code reuse, in the later (prototypal) -- unclassified (or "chaotic") code reuse, i.e. "I reuse/inherit the behavior and state from that object from which I want". There are no other differences. The implementation details are derived stuff. Moreover, the same implementation can provide both, classical and prototypal _approaches_ of a code reuse (good examples: Python - prototype-based language, CoffeeScript, JavaScript, etc). Because a "class" isn't a syntactic construct, inst' some specific implementation. It's the _ability to classify_ objects. And this ability can be achieved in different systems regardless an implementation. So if you need a classical code reuse with predefined "shapes" of your objects - you build a classical system reusing the code form linear ("tower") chain of inheritance. If instead you need just reuse a small functionality regardless of the classical hierarchy -- you use prototypal inheritance, that is delegation based traits/mixins/prototypes. And JS has both of them -- classes (without sugar) and prototypes -- and they both can be used when needed, there is no "bad practice" in this case. Regarding classes and their kinds (that's why Python is also prototype-based langauge with "classes as sugar", the same as in Coffee, the same as is planed for ECMAScript): https://gist.github.com/977034 https://gist.github.com/977034 You may find additional info on common theory of OOP and in particular in ECMAScript with all details in "ECMA-262-3 in detail. Chapter 7.1 / 7.2". Dmitry.