6 ms·

Prototypes are Objects

79 points by shawndumas 11y ago

seanmcdirmid 11y ago
This is an old debate that has been resolved (at least back then) since what is called "the Treaty of Orlando" at OOPSLA 1987; here is a public paper written afterward: http://web.media.mit.edu/~lieber/Publications/Treaty-of-Orlando-Chapter.pdf http://web.media.mit.edu/~lieber/Publications/Treaty-of-Orla... Abstract: > For the past few years, researchers have been debating the relative merits of object-oriented programming languages (OOPLs) with classes and inheritance as opposed to those with prototypes and delegation. It has become clear that the OOPL design space is not a dichotomy. Instead, we have identified two fundamental mechanisms, templates and empathy, and several different independent degrees of freedom for each. Templates create new objects in their own image, providing guarantees about the similarity of group members. Empathy allows an object to act as if it were some other object, providing sharing of state and behavior. Smalltalk, Actors, Lieberman''s delegation system, Self, and Hybrid each take differing stands on the forms of templates and empathy. Some varieties of template and empathy mechanisms are appropriate for building well-understood programs that must be extremely reliable; others are better suited for rapidly prototyping solutions to difficult problems. The differences between languages designed for each of these application domains can be recast as the differences between support for anticipated vs. unanticipated sharing. One can even ascribe the ascent of object-oriented programming to its strong support for extension instead of modification. However, many kinds of extension still remain difficult. The decomposition of an object-oriented language into template and empathy mechanisms and the degree of support for extension provided by the forms of these mechanisms provide a solid framework for studying language design.
- deleted 11y ago
  [deleted]
- jivardo_nucci 11y ago
  "Empathy? Empathy? We don't need no stinkin' empathy!" Uh, perhaps you meant "delegation"? No one uses the term "empathy" in reference to any OOP languages AFAICT except the authors of that non-text searchable paper written in 1987 that you reference. Even if _they_ used the term "empathy" it would have been better to use "delegation" in describing the paper, because to not do so reduces the empathy of your audience. [I am thorry, I could not resithd, but muth go now becauth I have an appointment with the delegation of the ambatthador at the the U.S. empathy].
julee04 11y ago
for any particular reason are you returning "this" in your rename function?
- pags 11y ago
  Probably for chaining
  - thomasfoster96 11y ago
    Definitely for chaining.
    - mckoss 11y ago
      Chaining. Definitely for chaining.
      - look_lookatme 11y ago
        Chaining. Chaining. Definitely for chaining.
        the_gipsy 11y ago
        TypeError: Cannot read property 'reply' of null
        thomasfoster96 11y ago
        //TODO: Make reply a method.
AnEngineer 11y ago
While the observations I am about to make likely will be down-voted by some/many in this forum, perhaps even be viewed as heresy, I am compelled to present them on the chance that it helps some to understand what JavaScript objects truly are. TL;DR JavaScript "objects" are nothing more than a <a href="https://en.wikipedia.org/wiki/Hash_table">Hash https://en.wikipedia.org/wiki/Hash_table">Hash map</a>. From the article: > Prototypes in JavaScript are “just objects,” and since they are “just objects,” we can add, remove, or modify methods of the prototype by adding, removing, or modifying the functions bound to properties of the prototype. They are not "just objects." In fact, symantically they are nothing more than a hash map (a.k.a. hash table, dictionary)[1]. The above quote from the article clearly indicates this fact as, if we peform three simple keyword substitutions, the sentence reads thusly: Prototypes in JavaScript are “just hash maps,” and since they are “just hash maps,” we can add, remove, or modify values of the prototype by adding, removing, or modifying the values bound to keys of the prototype. Attempting to think of JavaScript objects in the same manner as what most mainstream "OO" languages semantically provide is simply wrong. "Prototypical inheiritance" is nothing more than a shallow copy of an associative array. By its very definition, that is _all it is_. Now, IMHO there is nothing wrong with a hash map. There's nothing right about it either. Those sentiments imply judgement, whereas what I have said above is simply analyzing the nature of the subject. The fallacy in calling JavaScript "objects" objects lies in deceiving one's self into thinking that the same semantic guarantees OO languages provide can be done in native JavaScript. The quicker a developer accepts that JavaScript objects are simply hash maps, the quicker they can understand the semantic contract being proffered by the environment _and_ be able to work with it as best as possible. 1 - http://www.w3schools.com/js/js_object_definition.asp http://www.w3schools.com/js/js_object_definition.asp
- seanmcdirmid 11y ago
  I would argue that objects are nothing more than a uniquely identified run-time entity. With that identity, they can easily have their own encapsulated state (since their identity can be used as an address or key into a global map), and can be associated with behavior that is selected dynamically. Compare this with the dual of an object, the value, whose identity is determined by its structure alone (e.g. 1 and 1 are the same values), and so does not allow for state, nor does it allow for dynamic behavior selection without first turning them into objects (aka boxing). The implications of object-ness lead to certain styles of computation (noun-based) just as they do for values (expression oriented and functional). Objects existed in PL before the more limited kind in Java or even C++, not to mention the powerful but very Java-unlike object systems Self and CLOS that directly influenced JavaScript's design from the beginning. The only fallacy, I think, is ascribing a notion of objects based on a couple of mainstream data points. Objects are much richer than that.
rootedbox 11y ago
"JavaScript’s choice to build OOP out of simple parts–objects, functions, and properties–makes the development of new ideas possible." They did things like every other language basically. Everything is a pointer, and types are just abstractions we placed on things. So Functions, Objects, Properties can be passed around just like any other variable or even merged together fairly easily. Some languages hide this from you.. some require that you ask very nicely if you do things like this(pascal).. and others simply don't care what you do(c++).
barrkel 11y ago
Mixins need to be used with great care in dynamically typed languages. It's extremely easy to introduce dependencies on symbols in the class you're getting mixed into, and in larger projects it's not difficult to get name clashes between methods defined in different mixins, so that earlier mixins get clobbered by later mixins. From my experience, I'm not a big fan of mixin-heavy development. Mixins need a lot of discipline. A mixin probably shouldn't exist if it doesn't have at least two, if not three different target classes it is mixed into. I've seen mixins used for almost evil things in Rails. When mixins start adding before filters to controllers, disturbing amounts of magic can occur. You can end up needing to research a whole dependency dag and details of its implementation before you can understand a single method that may not refer to a mixin by symbol at all.
- masklinn 11y ago
  Self really had a nice solution to the issue: multiple named prototypes, properties not found on the root object would be looked up in all prototypes, and an error would be raised if multiple prototypes matched (requiring explicit resolution on the root object).
- hynieru 11y ago
  Depending on the use case the name clashing problem can be easily solved. For instance, in Lua the way I solve it is by simply letting multiple mixins define the same function, and whenever that function is called anywhere it triggers all of them. For game development this is extremely useful since usually when you have something like object:takeHit(attacker), multiple mixins that do different things in relation to getting hit (damage calculations, effects, animation, physics for pushback, and so on) define the takeHit function, but each of those different concerns is well hidden into their own separate mixin/module. Of course I agree with you that mixins need a lot of discipline and I specifically follow the 2-3 different target classes rule. It's really really easy to fall into the trap of making everything a mixin but this is really the wrong way to go about it.
- seanmcdirmid 11y ago
  They work well enough in statically typed languages, e.g. Scala, but that is more like diamond-avoiding linearized multiple inheritance.

79 points by shawndumas 11y ago

This is an old debate that has been resolved (at least back then) since what is called "the Treaty of Orlando" at OOPSLA 1987; here is a public paper written afterward: http://web.media.mit.edu/~lieber/Publications/Treaty-of-Orlando-Chapter.pdf http://web.media.mit.edu/~lieber/Publications/Treaty-of-Orla... Abstract: > For the past few years, researchers have been debating the relative merits of object-oriented programming languages (OOPLs) with classes and inheritance as opposed to those with prototypes and delegation. It has become clear that the OOPL design space is not a dichotomy. Instead, we have identified two fundamental mechanisms, templates and empathy, and several different independent degrees of freedom for each. Templates create new objects in their own image, providing guarantees about the similarity of group members. Empathy allows an object to act as if it were some other object, providing sharing of state and behavior. Smalltalk, Actors, Lieberman''s delegation system, Self, and Hybrid each take differing stands on the forms of templates and empathy. Some varieties of template and empathy mechanisms are appropriate for building well-understood programs that must be extremely reliable; others are better suited for rapidly prototyping solutions to difficult problems. The differences between languages designed for each of these application domains can be recast as the differences between support for anticipated vs. unanticipated sharing. One can even ascribe the ascent of object-oriented programming to its strong support for extension instead of modification. However, many kinds of extension still remain difficult. The decomposition of an object-oriented language into template and empathy mechanisms and the degree of support for extension provided by the forms of these mechanisms provide a solid framework for studying language design.

deleted 11y ago
[deleted]
jivardo_nucci 11y ago
"Empathy? Empathy? We don't need no stinkin' empathy!" Uh, perhaps you meant "delegation"? No one uses the term "empathy" in reference to any OOP languages AFAICT except the authors of that non-text searchable paper written in 1987 that you reference. Even if _they_ used the term "empathy" it would have been better to use "delegation" in describing the paper, because to not do so reduces the empathy of your audience. [I am thorry, I could not resithd, but muth go now becauth I have an appointment with the delegation of the ambatthador at the the U.S. empathy].

julee04 11y ago

for any particular reason are you returning "this" in your rename function?

pags 11y ago
Probably for chaining
- thomasfoster96 11y ago
  Definitely for chaining.
  - mckoss 11y ago
    Chaining. Definitely for chaining.
    - look_lookatme 11y ago
      Chaining. Chaining. Definitely for chaining.
      - the_gipsy 11y ago
        TypeError: Cannot read property 'reply' of null
        thomasfoster96 11y ago
        //TODO: Make reply a method.

AnEngineer 11y ago

While the observations I am about to make likely will be down-voted by some/many in this forum, perhaps even be viewed as heresy, I am compelled to present them on the chance that it helps some to understand what JavaScript objects truly are. TL;DR JavaScript "objects" are nothing more than a <a href="https://en.wikipedia.org/wiki/Hash_table">Hash https://en.wikipedia.org/wiki/Hash_table">Hash map</a>. From the article: > Prototypes in JavaScript are “just objects,” and since they are “just objects,” we can add, remove, or modify methods of the prototype by adding, removing, or modifying the functions bound to properties of the prototype. They are not "just objects." In fact, symantically they are nothing more than a hash map (a.k.a. hash table, dictionary)[1]. The above quote from the article clearly indicates this fact as, if we peform three simple keyword substitutions, the sentence reads thusly: Prototypes in JavaScript are “just hash maps,” and since they are “just hash maps,” we can add, remove, or modify values of the prototype by adding, removing, or modifying the values bound to keys of the prototype. Attempting to think of JavaScript objects in the same manner as what most mainstream "OO" languages semantically provide is simply wrong. "Prototypical inheiritance" is nothing more than a shallow copy of an associative array. By its very definition, that is _all it is_. Now, IMHO there is nothing wrong with a hash map. There's nothing right about it either. Those sentiments imply judgement, whereas what I have said above is simply analyzing the nature of the subject. The fallacy in calling JavaScript "objects" objects lies in deceiving one's self into thinking that the same semantic guarantees OO languages provide can be done in native JavaScript. The quicker a developer accepts that JavaScript objects are simply hash maps, the quicker they can understand the semantic contract being proffered by the environment _and_ be able to work with it as best as possible. 1 - http://www.w3schools.com/js/js_object_definition.asp http://www.w3schools.com/js/js_object_definition.asp

seanmcdirmid 11y ago
I would argue that objects are nothing more than a uniquely identified run-time entity. With that identity, they can easily have their own encapsulated state (since their identity can be used as an address or key into a global map), and can be associated with behavior that is selected dynamically. Compare this with the dual of an object, the value, whose identity is determined by its structure alone (e.g. 1 and 1 are the same values), and so does not allow for state, nor does it allow for dynamic behavior selection without first turning them into objects (aka boxing). The implications of object-ness lead to certain styles of computation (noun-based) just as they do for values (expression oriented and functional). Objects existed in PL before the more limited kind in Java or even C++, not to mention the powerful but very Java-unlike object systems Self and CLOS that directly influenced JavaScript's design from the beginning. The only fallacy, I think, is ascribing a notion of objects based on a couple of mainstream data points. Objects are much richer than that.

rootedbox 11y ago

"JavaScript’s choice to build OOP out of simple parts–objects, functions, and properties–makes the development of new ideas possible." They did things like every other language basically. Everything is a pointer, and types are just abstractions we placed on things. So Functions, Objects, Properties can be passed around just like any other variable or even merged together fairly easily. Some languages hide this from you.. some require that you ask very nicely if you do things like this(pascal).. and others simply don't care what you do(c++).

barrkel 11y ago

Mixins need to be used with great care in dynamically typed languages. It's extremely easy to introduce dependencies on symbols in the class you're getting mixed into, and in larger projects it's not difficult to get name clashes between methods defined in different mixins, so that earlier mixins get clobbered by later mixins. From my experience, I'm not a big fan of mixin-heavy development. Mixins need a lot of discipline. A mixin probably shouldn't exist if it doesn't have at least two, if not three different target classes it is mixed into. I've seen mixins used for almost evil things in Rails. When mixins start adding before filters to controllers, disturbing amounts of magic can occur. You can end up needing to research a whole dependency dag and details of its implementation before you can understand a single method that may not refer to a mixin by symbol at all.

masklinn 11y ago
Self really had a nice solution to the issue: multiple named prototypes, properties not found on the root object would be looked up in all prototypes, and an error would be raised if multiple prototypes matched (requiring explicit resolution on the root object).
hynieru 11y ago
Depending on the use case the name clashing problem can be easily solved. For instance, in Lua the way I solve it is by simply letting multiple mixins define the same function, and whenever that function is called anywhere it triggers all of them. For game development this is extremely useful since usually when you have something like object:takeHit(attacker), multiple mixins that do different things in relation to getting hit (damage calculations, effects, animation, physics for pushback, and so on) define the takeHit function, but each of those different concerns is well hidden into their own separate mixin/module. Of course I agree with you that mixins need a lot of discipline and I specifically follow the 2-3 different target classes rule. It's really really easy to fall into the trap of making everything a mixin but this is really the wrong way to go about it.
seanmcdirmid 11y ago
They work well enough in statically typed languages, e.g. Scala, but that is more like diamond-avoiding linearized multiple inheritance.