4 ms·

Is there a good resource that shows the ideal use of prototypal inheritance? I imagine that the ideal use is not mimicking class-based inheritance, or is it? I

by jolmg 7y ago

Is there a good resource that shows the ideal use of prototypal inheritance? I imagine that the ideal use is not mimicking class-based inheritance, or is it? I mean if you have an array of things and you want a new instance of such things, it's too unnatural to take one from the array, clone it and change it. It seems more natural to have something class-like: An "empty" prototype and a constructor function. I guess what I'm wondering is what idioms and patterns are unique to prototypal-inheritance OOP languages.

Crinus 7y ago
Chances are those things were cloned from something else so you can simply clone that something else and put the clone in the array. AFAIK (though my knowledge is limited) in Self there isn't a language-endorsed prototype like in JavaScript, instead an object is just a collection of slots and some slots can be marked as parent slots meaning that whenever slot lookup is made on an object, that object's parent objects will also be looked up. Prototypes are just a convention. This implies that there isn't a "this is of class foo" connection (outside of manual conventions) and hence you do not have an "array of things" but an "array of objects" and each one of these objects can be anything - it is up to the rest of the code to ensure (or not) any similarity between the objects stored in the array. FWIW the Self Handbook does seem to have a section on programming style and generally does seem to write a bit about how you are supposed to work with the system.
- masklinn 7y ago
  > AFAIK (though my knowledge is limited) in Self there isn't a language-endorsed prototype like in JavaScript, instead an object is just a collection of slots and some slots can be marked as parent slots meaning that whenever slot lookup is made on an object, that object's parent objects will also be looked up. That's correct, although incomplete: parents are only used when no "own" slot matches a message. Self will also trigger an error if two parents answer to the same message. > Prototypes are just a convention. Not so, however "prototype" has a completely different meaning in Self than it has in Javascript: a Self prototype is a mostly set-up object to copy, there is no semantic relation between a prototype and its "instance" afterwards. In Self, an object built to be set on a parent slot (and shared between multiple sub-objects) will be called either a trait or a mixin (depending on its parent chains, essentially). Self parent slots are no more and no less than built-in delegation. They can be used for inheritance (traits), they can be used for sharing implementation (mixins) or they can be used in the general context of composition (Go has echoes of this in struct embedding).
Someone 7y ago
”it's too unnatural to take one from the array, clone it and change it. It seems more natural to have something class-like: An "empty" prototype and a constructor function.” That may only feel more natural to you because you are used to a Platonic/Aristotelian view of the (programming) world (https://en.m.wikipedia.org/wiki/Aristotle#Epistemology https://en.m.wikipedia.org/wiki/Aristotle#Epistemology), where classes are defined as “that what all instances of it share” as opposed to a Wittgensteinian, who argued that there often isn’t anything that all of the instances of a class share. Games, for example, may or may be played on a board, have turns, and may not even have players (https://en.wikipedia.org/wiki/Conway's_Game_of_Life https://en.wikipedia.org/wiki/Conway's_Game_of_Life) Class-based modeling also breaks down when, for example, modeling mammals that may have two heads, four or five legs, defining ‘object of art’ (should, for example, be flexible enough to include some, but definitely not all urinals), etc. Also, with unica (happens a lot in UI programming, where most dialogs are unique, as https://cdn.preterhuman.net/texts/computing/apple/newton/Prototype-Based_Language_for_User_Interface_-_Newton_Projects_Experience.pdf https://cdn.preterhuman.net/texts/computing/apple/newton/Pro... argues) why split them into two, the class and its sole instantiation? Prototypical inheritance allows you to implement class-like behavior in the way you mention, but also is more flexible. One can implement the equivalent of static methods in the prototype, for example, create “once per class” state in intermediate objects, etc.
Stwerner 7y ago
For me, what really made it click and think about how different it is from class-based inheritance was an old Steve Yegge post: http://steve-yegge.blogspot.com/2008/10/universal-design-pattern.html http://steve-yegge.blogspot.com/2008/10/universal-design-pat... It is a really long post and heavily references Godel, Escher, Bach but this section I think explains the difference really well: Hofstadter offers several supporting examples for this thesis, but I'll paraphrase one of my all-time favorites. It goes more or less as follows. Imagine you're listening to announcers commenting on an NFL (American football) game. They're talking about a new rookie player that you don't know anything about. At this point, the rookie – let's say his name is L.T. – is just an instance of the class "football player" with no differentiation. The announcers mention that L.T. is a running back: a bit like Emmitt Smith in that he has great speed and balance, and he's great at finding holes in the defense. At this point, L.T. is basically an "instance" of (or a clone of) Emmitt Smith: he just inherited all of Emmitt's properties, at least the ones that you're familiar with. Then the announcers add that L.T. is also great at catching the ball, so he's sometimes used as a wide receiver. Oh, and he wears a visor. And he runs like Walter Payton. And so on. As the announcers add distinguishing attributes, L.T. the Rookie gradually takes shape as a particular entity that relies less and less on the parent class of "football player". He's become a very, very specific football player. But here's the rub: even though he's a specific instance, you can now use him as a class! If Joe the Rookie comes along next season, the announcers might say: "Joe's a lot like L.T.", and just like that, Joe has inherited all of L.T.'s properties, each of which can be overridden to turn Joe into his own specific, unique instance of a football player. This is called prototype-based modeling: Emmitt Smith was a prototype for L.T., and L.T. became a prototype for Joe, who in turn can serve as the prototype for someone else.
- nerdponx 7y ago
  That's a helpful explanation. How would a type system work in that context? Or is there no such thing?
  - Stwerner 7y ago
    Hah that's a good question. I haven't really thought about that or explored type systems that would interact with this pattern. Would be really interested in reading about it though!

by jolmg 7y ago

Crinus 7y ago

Chances are those things were cloned from something else so you can simply clone that something else and put the clone in the array. AFAIK (though my knowledge is limited) in Self there isn't a language-endorsed prototype like in JavaScript, instead an object is just a collection of slots and some slots can be marked as parent slots meaning that whenever slot lookup is made on an object, that object's parent objects will also be looked up. Prototypes are just a convention. This implies that there isn't a "this is of class foo" connection (outside of manual conventions) and hence you do not have an "array of things" but an "array of objects" and each one of these objects can be anything - it is up to the rest of the code to ensure (or not) any similarity between the objects stored in the array. FWIW the Self Handbook does seem to have a section on programming style and generally does seem to write a bit about how you are supposed to work with the system.

masklinn 7y ago
> AFAIK (though my knowledge is limited) in Self there isn't a language-endorsed prototype like in JavaScript, instead an object is just a collection of slots and some slots can be marked as parent slots meaning that whenever slot lookup is made on an object, that object's parent objects will also be looked up. That's correct, although incomplete: parents are only used when no "own" slot matches a message. Self will also trigger an error if two parents answer to the same message. > Prototypes are just a convention. Not so, however "prototype" has a completely different meaning in Self than it has in Javascript: a Self prototype is a mostly set-up object to copy, there is no semantic relation between a prototype and its "instance" afterwards. In Self, an object built to be set on a parent slot (and shared between multiple sub-objects) will be called either a trait or a mixin (depending on its parent chains, essentially). Self parent slots are no more and no less than built-in delegation. They can be used for inheritance (traits), they can be used for sharing implementation (mixins) or they can be used in the general context of composition (Go has echoes of this in struct embedding).

Someone 7y ago

”it's too unnatural to take one from the array, clone it and change it. It seems more natural to have something class-like: An "empty" prototype and a constructor function.” That may only feel more natural to you because you are used to a Platonic/Aristotelian view of the (programming) world (https://en.m.wikipedia.org/wiki/Aristotle#Epistemology https://en.m.wikipedia.org/wiki/Aristotle#Epistemology), where classes are defined as “that what all instances of it share” as opposed to a Wittgensteinian, who argued that there often isn’t anything that all of the instances of a class share. Games, for example, may or may be played on a board, have turns, and may not even have players (https://en.wikipedia.org/wiki/Conway's_Game_of_Life https://en.wikipedia.org/wiki/Conway's_Game_of_Life) Class-based modeling also breaks down when, for example, modeling mammals that may have two heads, four or five legs, defining ‘object of art’ (should, for example, be flexible enough to include some, but definitely not all urinals), etc. Also, with unica (happens a lot in UI programming, where most dialogs are unique, as https://cdn.preterhuman.net/texts/computing/apple/newton/Prototype-Based_Language_for_User_Interface_-_Newton_Projects_Experience.pdf https://cdn.preterhuman.net/texts/computing/apple/newton/Pro... argues) why split them into two, the class and its sole instantiation? Prototypical inheritance allows you to implement class-like behavior in the way you mention, but also is more flexible. One can implement the equivalent of static methods in the prototype, for example, create “once per class” state in intermediate objects, etc.

Stwerner 7y ago

For me, what really made it click and think about how different it is from class-based inheritance was an old Steve Yegge post: http://steve-yegge.blogspot.com/2008/10/universal-design-pattern.html http://steve-yegge.blogspot.com/2008/10/universal-design-pat... It is a really long post and heavily references Godel, Escher, Bach but this section I think explains the difference really well: Hofstadter offers several supporting examples for this thesis, but I'll paraphrase one of my all-time favorites. It goes more or less as follows. Imagine you're listening to announcers commenting on an NFL (American football) game. They're talking about a new rookie player that you don't know anything about. At this point, the rookie – let's say his name is L.T. – is just an instance of the class "football player" with no differentiation. The announcers mention that L.T. is a running back: a bit like Emmitt Smith in that he has great speed and balance, and he's great at finding holes in the defense. At this point, L.T. is basically an "instance" of (or a clone of) Emmitt Smith: he just inherited all of Emmitt's properties, at least the ones that you're familiar with. Then the announcers add that L.T. is also great at catching the ball, so he's sometimes used as a wide receiver. Oh, and he wears a visor. And he runs like Walter Payton. And so on. As the announcers add distinguishing attributes, L.T. the Rookie gradually takes shape as a particular entity that relies less and less on the parent class of "football player". He's become a very, very specific football player. But here's the rub: even though he's a specific instance, you can now use him as a class! If Joe the Rookie comes along next season, the announcers might say: "Joe's a lot like L.T.", and just like that, Joe has inherited all of L.T.'s properties, each of which can be overridden to turn Joe into his own specific, unique instance of a football player. This is called prototype-based modeling: Emmitt Smith was a prototype for L.T., and L.T. became a prototype for Joe, who in turn can serve as the prototype for someone else.

nerdponx 7y ago
That's a helpful explanation. How would a type system work in that context? Or is there no such thing?
- Stwerner 7y ago
  Hah that's a good question. I haven't really thought about that or explored type systems that would interact with this pattern. Would be really interested in reading about it though!