Pseudoclassical Inheritance vs. Functional Inheritance

[00:00:00]
>> [MUSIC]

[00:00:03]
>> Douglas Crockford: So let's compare this to the pseudoclassical model. So you remember this. It's just awful with all this stuff hanging around. So this is the same thing now in this functional model. And the code gets a lot cleaner. For one thing, we don't have the .prototype stuff hanging off the end.

[00:00:25]
Everything is nice and neat and contained within here. So the gizmo constructor very simple, it's simply returning a new object. Notice the curly braces are on the right. So this is gonna work perfectly. Instead of saying this.id equals id, we simply say id:id and we're done. Then our who's it is going to make a new gizmo.

[00:00:52]
And we're then going to add to that function our test method or add to that object our test method. Return the object and it's done. So the code got a lot simpler as well. Yeah?
>> Speaker 2: I think about ten minutes ago, you were saying not to use this, or that you didn't recommend it or even like it.

[00:01:12]
>> Douglas Crockford: Yeah, that's the next step.
>> Speaker 2: Okay.
>> Douglas Crockford: So let's suppose we want to have privacy, which is something that I think is very important to have in object systems. So that we may have a goal where the only way to get access to the ID is through the methods of the object that we don't want anybody to be able to access ID except through the methods.

[00:01:39]
JavaScript doesn't provide any way of having privacy in the classical model, in the pseudo-classical model, because everything you attach to an object is visible to anybody who gets access to the object. So there's no privacy there. But the functional model, because we have functions scope in closure, we do.

[00:01:59]
So let's say we want to hide the IDs. You can only get ID through the two string test methods. The code actually gets simpler. So instead of saying this.id here we simply say id, and we're getting it from, we're closing over the variable that got passed in. So it's private, it's completely private.

[00:02:22]
And this code got simpler too. We got this ID, and which again, we're getting through closure and the code got smaller and simpler. Yeah.
>> Speaker 3: Aren't the functions copied, though, then for each instance?
>> Douglas Crockford: Right, so there is a cost to this model. That in the prototypal model we're saving memory, because we only have one of each method per instance.

[00:02:47]
In this one we're going to have lots more function objects being created. And we'll talk more about this on Friday, but it turns out that that's significant only if you've got millions of instances. That memory has become so expansive, you've got gigabytes of RAM in your pocket. Making important architectural decisions based on memory conservation is not a good way to go now.

[00:03:17]
And I would contend that if you are worried about millions of instances, maybe this is not the language you should be using. But for most of what we do, the number of objects that you're gonna make is gonna be relatively small. And performance-wise, this is gonna be great.

[00:03:36]
So we're gonna spend a little bit more in construction, but we're gonna spend a lot less in execution. So I think it's a win.
>> Speaker 2: That fact that you create an instance of that function for each instance of the object, that's because of closure, right? If we can't have closure without that.

[00:04:02]
>> Douglas Crockford: That's right.
>> Speaker 2: Okay.
>> Douglas Crockford: Yeah, because of closure, we're willing to pay that cost.
>> Speaker 2: Right.
>> Douglas Crockford: And it's not much of a cost. If you look at what is in a function object, there is basically an object with two extra pointers in it. One for the pointer to the code, and one the pointer to the activation of the creating function.

[00:04:26]
There's not much else in there. There will be a link to the prototype object, which is a waste because we're not going to use that. That's it. So, there's not much memory in those things, not a lot of work to initialize them. So it's very lightweight.
>> Douglas Crockford: Anybody else?

[00:04:55]
>> Douglas Crockford: So this also solves another problem that we have in the language which is related to this binding. So this is the old hoozit, the original pseudo-classical hoozit. Suppose we want to take the test function out of the object. Which we can do because you can copy any object reference out of an object and put it in a separate variable, and then call that variable as a function.

[00:05:20]
That call will fail because when we call test as a function, this will be bound not to the object that it came from but to something else, either to the global object or undefined. Either of which will cause this test to fail. But in the new form because our methods do not have this in them, we can take those functions, pull them out of the object, and call them independently, and they still work exactly the same way because they don't depend on this.

[00:05:55]
So no matter how those methods are called, they will always work correctly. All the fragileness of this is completely avoided.
>> Speaker 4: Just so I'm clear on this, in the middle one there, in your function where you're taking the Test ID, you have access to ID because it was pushed onto the heap, and it hasn't been garbage collected yet because it's rooted somewhere.

[00:06:22]
>> Douglas Crockford: Right.
>> Speaker 4: Okay.
>> Douglas Crockford: Yeah, in fact, it's being rooted by that object.
>> Speaker 4: Yeah.
>> Douglas Crockford: Or by that method. As long as that method survives, the context it needs will also survive.
>> Speaker 4: Okay.