3 ms·

Thanks for the comment. I have added big red (orange ...) boxes to let the user know that it is considered bad practice. The objective of the article is to exp

by vjeux 15y ago

Thanks for the comment. I have added big red (orange ...) boxes to let the user know that it is considered bad practice. The objective of the article is to explain how prototypal inheritance works and how it relates to the new operator. The use of real prototypal inheritance was added at the end, just to note that it was possible.

DmitrySoshnikov 15y ago
> 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.

by vjeux 15y ago

DmitrySoshnikov 15y ago

> 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.