The prototypal school has a lot of advantages particularly compared to the classical school
So in the classical school you have to create a classification of all the objects that are likely to be in your system. And, it's a lot of work to figure out what they all are and identify them and what their characteristics are and so on and then you have to determine how they are all related to each other, what’s going to inherit from what, what’s going to implement what, what’s going to interface with what, and that’s really complicated. And it usually happens at the beginning of the project before you fully understand what all this stuff means. So it’s likely your going to get the taxonomy wrong. It’s inevitable.
And then you’ve got two hard choices. One is you have to live with a broken taxonomy and if you do that then with each new class you introduce things get weirder and weirder because everything’s wrong, or you have to refactor and refactoring is hard and it’s error prone and it’s another world of hurt.
Those are your two choices and people who grew up in the classical school assume that’s just the way life is so no sense in complaining about it since that’s life.
But in the prototypal school you don’t do any of that. You just make an object, if you don’t like the way it works you make another one and that is literally it.
So you can tell people from the classical school “You don’t have to do all of that” and they go “Yea, I hear ya, but you still have to do it” and you say “no, you don’t have to do it” and they go “yea, yea, yea” (blowing you off)
And so that’s why I think classes in ES6 are a bad part because they lock you into that paradigm.
applause
So when you’re locked in a paradigm like that, when you can’t see past it, you just have no understanding how miserable you are. And you’ll never know until you change your model
…
so I used to think that the important thing in JavaScript was prototypal inheritance I now think it is Class Free object oriented programing. I think that is JavaScript’s gift to humanity. That’s the thing that makes it a really interesting important language, is that it did that. That we can use functions in order to create objects and it simple and elegant and powerful and fast, it uses more memory than that other thing but who cares.
…
this is how I am making objects in JavaScript now
function constructor(spec) {
var that = other_constructor(spec),
member,
method = function() {
// spec, member, method
};
that.method = method;
return that;
}
from https://www.youtube.com/watch?v=bo36MrBfTk4#t=28m50s
He mentions he no longer uses new
and no longer uses this
. He's completely stopped using both classical school style OO and prototypal style OO and instead builds objects as above. It might not make sense if you're not familiar with JavaScript. Assume other constructor looks like this
function other_constructor(spec) {
var that = {},
member,
someMethod = function() {
// spec, member, someMethod
};
that.someMethod = someMethod;
return that;
}
Basically he makes an empty object {}
and then starts adding methods to it. Calling other_constructor
lets other_constructor
add its methods first, then he adds more. In constructor
, method
has access to spec
, member
which is a completely private variable, and method
.
I think the point is that with lazy binding or whatever you call it, the fact that every reference to a property of an object is a hash lookup in JS, you can just build objects on the fly. No need to inherit from anything, no need to create interfaces first because the language doesn't care. If you call someOb.foo()
it's going to look, at runtime, in a hash map for foo
inside someOb
and then call the function. Note, a game dev might freak out because of the time to look up the hash and it's certainly not free but JS JITers effectively generate code that caches the look up, something like
if (!oldLookupForFooStillValid()) {
lookUpFoo();
}
callFoo();
I don't know what the overhead for that is. I'm sure it's not as small as a vtable lookup for classical inheritance but whether it really matters for most use cases is debatable.
He does briefly praise Smalltalk 80 in that talk, which certainly had classes and inheritance. Common Lisp added OOP to it's standard a few years later, which included classes and inheritance. Maybe he thinks the C++ and Java implementations are too rigid? But ES6 classes are syntactic sugar over constructors and prototypes, so you're not losing flexibility.