4 ms·

The OP argues well that it is not inheritance, but neither does the term "delegation" fit. For example, when I delegate a task to someone at work, that person i

The OP argues well that it is not inheritance, but neither does the term "delegation" fit. For example, when I delegate a task to someone at work, that person is not expected to wear my shirt to work. The delegate is expected to complete the task using resources available to the delegate. Delegates are better viewed therefore as processes. If JS's facilities are viewed as inheritance or delegation, the language ends up being used in limited ways to express solutions. There is nothing sacrosanct about classes. I agree with the original authors of Self that one tends to freeze categories early on in a class based language, whereas in a prototypal system, the categories are fluid, with structure that can evolve over time as knowledge about the problem domain improves.

lispm 13y ago
I would not expect real-world behavior for programming language constructs. Terms like 'inheritance' and 'delegation' are so vague, that it gives only a very rough indication what it does in some programming language. If I want to understand a programming language feature, I read the language spec, a manual, or, if all fails, the source code of the implementation.
- aufreak3 13y ago
  > I would not expect real-world behavior for programming language constructs. While that's indeed an invalid expectation, the term "delegate" is used technically in Objective-C, for example, in a way that cannot be related to "prototypal inheritance". The "delegates" don't use the resources of the delegating object. Quite often, they provide resources or data to the delegating object. JS's prototype system doesn't fit this model of "delegate" either 'cos the "delegate" does appear as though it is wearing the delegating object's shirt. The delegate itself (if you still want to call it one) has no identity apart from the delegating object in JS, whereas that isn't the case in ObjC. > If I want to understand a programming language feature This is not so much about understanding a language feature. It is about a model of system design being force fitted onto the language constructs. The language feature itself is dead simple and doesn't need to be viewed through the filter of OO to "understand" it.
  - lispm 13y ago
    Names are used in various contexts with different meaning. There is nothing unusual about that. If I would want to learn about prototype OO, I would check out the founding papers. Stuff like: http://selflanguage.org/_static/published/parents-shared-parts.pdf http://selflanguage.org/_static/published/parents-shared-par... Parents are Shared Parts of Objects: Inheritance and Encapsulation in SELF http://web.media.mit.edu/~lieber/Lieberary/OOP/Delegation/Delegation.html http://web.media.mit.edu/~lieber/Lieberary/OOP/Delegation/De... Using Prototypical Objects to Implement Shared Behavior in Object Oriented Systems 'Delegation' in Objective-C is a different mechanism.
  - _getify 13y ago
    The fact that Objective-C has a term "delegate" does not mean I can't argue that "behavior delegation" is an accurate term for any prototypical-inheritance mechanism, specifically JS's. Objective-C taking a specific meaning for that term is nowhere near as ubiquitous as the point I made that "inheritance" has been so well defined across so many class-oriented languages (for decades!) that borrowing the term for [[Prototype]] is a confusing mistake.
_getify 13y ago
As the OP, I would argue that your metaphor actually does match well how delegation works not only in the real world, but also in JS. For example, if I'm given a task by my boss, and he says "just make sure it gets done", I'll have a set of materials, say the specifications for a task, or an email thread discussing it, or something like that. When I decide to "delegate" it to another person on the team, I'm not going to expect that person to start from scratch... I'm going to hand them the "context" for them to tackle the task in. I'm going to say: "here's what you need to get started, go do it." Metaphors are never perfect, by definition. But I take that perspective on your metaphor, and on JS's behavior delegation, and I think it fits decently.

lispm 13y ago

I would not expect real-world behavior for programming language constructs. Terms like 'inheritance' and 'delegation' are so vague, that it gives only a very rough indication what it does in some programming language. If I want to understand a programming language feature, I read the language spec, a manual, or, if all fails, the source code of the implementation.

aufreak3 13y ago
> I would not expect real-world behavior for programming language constructs. While that's indeed an invalid expectation, the term "delegate" is used technically in Objective-C, for example, in a way that cannot be related to "prototypal inheritance". The "delegates" don't use the resources of the delegating object. Quite often, they provide resources or data to the delegating object. JS's prototype system doesn't fit this model of "delegate" either 'cos the "delegate" does appear as though it is wearing the delegating object's shirt. The delegate itself (if you still want to call it one) has no identity apart from the delegating object in JS, whereas that isn't the case in ObjC. > If I want to understand a programming language feature This is not so much about understanding a language feature. It is about a model of system design being force fitted onto the language constructs. The language feature itself is dead simple and doesn't need to be viewed through the filter of OO to "understand" it.
- lispm 13y ago
  Names are used in various contexts with different meaning. There is nothing unusual about that. If I would want to learn about prototype OO, I would check out the founding papers. Stuff like: http://selflanguage.org/_static/published/parents-shared-parts.pdf http://selflanguage.org/_static/published/parents-shared-par... Parents are Shared Parts of Objects: Inheritance and Encapsulation in SELF http://web.media.mit.edu/~lieber/Lieberary/OOP/Delegation/Delegation.html http://web.media.mit.edu/~lieber/Lieberary/OOP/Delegation/De... Using Prototypical Objects to Implement Shared Behavior in Object Oriented Systems 'Delegation' in Objective-C is a different mechanism.
- _getify 13y ago
  The fact that Objective-C has a term "delegate" does not mean I can't argue that "behavior delegation" is an accurate term for any prototypical-inheritance mechanism, specifically JS's. Objective-C taking a specific meaning for that term is nowhere near as ubiquitous as the point I made that "inheritance" has been so well defined across so many class-oriented languages (for decades!) that borrowing the term for [[Prototype]] is a confusing mistake.

_getify 13y ago

As the OP, I would argue that your metaphor actually does match well how delegation works not only in the real world, but also in JS. For example, if I'm given a task by my boss, and he says "just make sure it gets done", I'll have a set of materials, say the specifications for a task, or an email thread discussing it, or something like that. When I decide to "delegate" it to another person on the team, I'm not going to expect that person to start from scratch... I'm going to hand them the "context" for them to tackle the task in. I'm going to say: "here's what you need to get started, go do it." Metaphors are never perfect, by definition. But I take that perspective on your metaphor, and on JS's behavior delegation, and I think it fits decently.