|
See: http://www.c2.com/cgi/wiki?ClassesPrototypesComparison In my experience, prototype-based OOP is less prone to the typical OOP over-analysis - if you just need one object that does something, you just assemble it, that's it, problem solved. Since the default stance isn't designing a generic class for all possible subtypes that exhibit related behavior and blah blah blah, there's less push toward overthinking things. Prototype-based OOP is also well-suited to runtime modification, since the underlying implementation is usually simpler, but that's a distant second to the above benefit. And while prototypes are sometimes assumed to be less efficient than classes, look at the research from Self* - While some popular languages have poor implementations, it's not inherently less efficient. Also, I suspect prototypes integrate more smoothly with non-OOP code than classes, based on experience with Lua (which isn't strictly OOP, but typically uses prototypes). To some extent, this blurs with dynamic typing, though - there's only one statically typed + prototype-based OOP language I know of, Günther Blaschek's Omega (described in _Object-Oriented Programming With Prototypes_). * http://selflanguage.org/documentation/published/index.html
Some of the people involved later worked on the "JVM". Perhaps you've heard of it? |
But that's not really a property of prototype languages - it's a property of duck typing. For example, Ruby - a non prototype language - can implement exactly the same idea. Take an instance of a class, and add a method specifically to that object - no problems. Critically, the thing that makes this possible is the fact that evaluation of the existence of the method is made at call time, not at compile time.