_getify

> If you try to illustrate behavior delegation in terms of the "blueprint" metaphor, you quickly see how it totally breaks down. There's no way that my home, lacking a guest bedroom, could simply refer to another house, or to the original blueprints, to provide a bedroom for my mother-in-law when she comes to visit.

OTOH, I can delegate my mother-in-law to go stay in a hotel room. Or, I can delegate my mother-in-law to stay on a neighbor's couch, but I can send along sheets and pillows for her to use.

In either case, I'm not mutating my own home (inheritance) to handle her visit, I'm relying on someone else to handle it. But it's still my mother-in-law who I send elsewhere, and in fact, I can make sure she takes some "context" (aka, pillows) with her when she does.

Again, metaphors are never perfect, but I just thought I'd complete the perspective to contrast inheritance vs. behavior delegation.

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.

The point I'd make about it here, though, which is generically reflected in today's part 2 article, is that it's a fine pattern in and of itself, but the reason I think it's a "distraction" is that it actually moves away from the [[Prototype]] chain entirely.

You can use it as a bespoke pattern for combining two objects, but it's a mistake/confusion to think this has anything to do with JS's underlying delegation mechanism. The same point is made about mixins, and polymorphism (which also requires implicit mixins).

In parts 2 and 3, I'll make the case for why I think all those things don't belong in JS and should be removed or avoided.

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.