3 ms·

See: http://www.c2.com/cgi/wiki?ClassesPrototypesComparison http://www.c2.com/cgi/wiki?ClassesPrototypesComparison In my experience, prototype-based OOP is les

See: http://www.c2.com/cgi/wiki?ClassesPrototypesComparison 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 http://selflanguage.org/documentation/published/index.html Some of the people involved later worked on the "JVM". Perhaps you've heard of it?

uros643 16y ago
See also Lisaac (http://en.wikipedia.org/wiki/Lisaac http://en.wikipedia.org/wiki/Lisaac), another prototype-based OO language that's statically typed.
demallien 16y ago
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. 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.
- silentbicycle 16y ago
  Dynamic and duck typing does help quite a bit there, but I think the default stance of prototypes rather than classes also makes a difference. The way I write object-centric code in Lua feels very different from in Python, even though both languages are dynamically typed (and otherwise fairly similar). It probably has to do with conventions / what's "Pythonic". I haven't used Ruby enough to comment.
  - deleted 16y ago
    [deleted]
  - demallien 16y ago
    I have to admit that I have a thing against prototyping languages, due to my experiences with Javascript in WebKit :) When you create a native object in Javascript you can't "subclass" it in Javascript, at least not by using the standard prototyping pattern. An example: function MySubclass() { } MySubclass.prototype = new MyNativeClass(); So far everything works as you would expect. Now I'm going to instantiate and initialise MySubclass: anObject = new MySubclass(); Again, so far ok. Now I'm going to call the initialiser on the object, which creates the native object and binds it to the javascript object anObject.init() Boom! Doesn't work, because Javascript objects (at least in JavascriptCore) can't be bound to a native object - a call to JSObjectSetPrivate() fails. Instead, I do inheritence this way: function MySubclass() { var that = new MyNativeClass(); var super_init = that.init; that.init = function() { } return that; } It works, but I'm no longer using the prototype nature of the language. I admit that this might be due to a flaw in the implementation (not allowing the private data to be set on objects with a Javascript constructor), but it certainly hasn't given my warm fuzzy feelings about protoyping...

uros643 16y ago

See also Lisaac (http://en.wikipedia.org/wiki/Lisaac http://en.wikipedia.org/wiki/Lisaac), another prototype-based OO language that's statically typed.

demallien 16y ago

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

silentbicycle 16y ago
Dynamic and duck typing does help quite a bit there, but I think the default stance of prototypes rather than classes also makes a difference. The way I write object-centric code in Lua feels very different from in Python, even though both languages are dynamically typed (and otherwise fairly similar). It probably has to do with conventions / what's "Pythonic". I haven't used Ruby enough to comment.
- deleted 16y ago
  [deleted]
- demallien 16y ago
  I have to admit that I have a thing against prototyping languages, due to my experiences with Javascript in WebKit :) When you create a native object in Javascript you can't "subclass" it in Javascript, at least not by using the standard prototyping pattern. An example: function MySubclass() { } MySubclass.prototype = new MyNativeClass(); So far everything works as you would expect. Now I'm going to instantiate and initialise MySubclass: anObject = new MySubclass(); Again, so far ok. Now I'm going to call the initialiser on the object, which creates the native object and binds it to the javascript object anObject.init() Boom! Doesn't work, because Javascript objects (at least in JavascriptCore) can't be bound to a native object - a call to JSObjectSetPrivate() fails. Instead, I do inheritence this way: function MySubclass() { var that = new MyNativeClass(); var super_init = that.init; that.init = function() { } return that; } It works, but I'm no longer using the prototype nature of the language. I admit that this might be due to a flaw in the implementation (not allowing the private data to be set on objects with a Javascript constructor), but it certainly hasn't given my warm fuzzy feelings about protoyping...