And there's another copy that happens when foo gets copied into a2. And when we create a child class called bar we're copying the behavior from foo down to bar and then another copy into bar's instances. This is not only a physical thing in terms of what the compiler is doing, but this is the most common way that metaphorically we explain how classes work, if any of you ever took computer science classes or whatever.
If you were ever taught, you were probably given the metaphor of the blueprints. The class represents the blueprints for some building, and then, so you have an architect that lays out the blueprints, but you have a builder than comes along and builds your building. Well, the builder is copying the characteristics from the plans into the physical building.
Once the physical building is built, there's no more relationship to the original plans. It's not like they're linked or tied in some way. It was a copy. So we can go back to biology and we can talk about parents and children. And when my child inherits my DNA, they get a copy of my DNA.
To me, that's like me holding up an apple in one hand and an orange in the other hand and saying, no, no, no, that's not an apple, it's just a red orange. You would look at me and say, that's ludicrous. Just because you put the word red in front of it doesn't make it an orange.
Or doesn't make it not an apple. It intrinsically is something based upon its characteristics, and what you call it, you can call it what it is or you can call it something else and confuse me. But what you call it doesn't change what it is. So in my opinion, inheritance means something.
It was a behavior link. It was a delegation link. So a1 is linked to foo.prototype, and a2 is linked to foo.prototype, and Bar.prototype is linked, and b1 and b2. The arrows go from right to left, and bottom to top, which is the complete opposite of the previous slide.
These mechanisms are fundamentally, in their very intrinsic DNA, they are opposite of each other. One of them is a copy down, one of them is a delegation up the chain. And what we've been trying to do for 20 years is make a mechanism that works like this pretend like it's a mechanism from the previous slide.
And we've been doing all kinds of things. You've heard of the mix in pattern, which manually copies things from one prototype to another and all manner of different variations on it. I could spend hours and hours talking about all the different variations. 100% of that is an attempt to make something that works like this look like it works like the previous slide.
So we're doing all of this work, and I think it's just hiding the fact that we could look at a mechanism that works like that and see how we could take advantage of that mechanism itself. Because that mechanism has a lot of power to it. This is another design pattern by the way.
Remember this code before when we say a1.speak? I've already used this word before but when a1 is able to call speak, you notice the way that the mechanism works. It wasn't because a1 got a copy of speak. The reason a1 was able to call speak is because he was able to delegate up to a different object that had a speak method on it.
It's a completely different mechanism than what happens with classes.