Skip to content

Instantly share code, notes, and snippets.

@greggman
Last active October 7, 2015 16:06
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save greggman/76b5db501e67021d3c35 to your computer and use it in GitHub Desktop.
Save greggman/76b5db501e67021d3c35 to your computer and use it in GitHub Desktop.
Words by Douglas Crockford

Classical (nearly every other language) vs Prototypal (javascripts) objects

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

notes from me

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.

@Mearnest
Copy link

Mearnest commented Oct 7, 2015

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment