FACT: After my post of a few days ago, I’m going to try to avoid beginning blog posts with the word “FACT”. I think labeling something as an ALL-CAPS FACT is just taunting someone to come along and dispute whatever you say. But anyway, I’ve already done it again.
OK, in the aforementioned post, I said that there were other, possibly … “better” ways of reusing code in JavaScript than by emulating classes. Take that “better” with a grain of salt. There are other ways, and some consider them better.
Prototypes
JavaScript is a prototype-based language. This means (as you can read for yourself in the link) that it creates new objects by cloning existing objects. The object you are cloning serves as the prototype of the new object. For now, just use the English language definition of prototype: “the original or model on which something is based or formed.” You have an object and you make a copy of it. It has all the properties and methods as the old one, and you can add new properties and methods to it. That’s how you get code reuse.
Now, a poor way to implement this would be to actually clone the existing object, copying over all its properties and methods to some new empty object. In that case, you’d wind up duplicating many of these properties on every single object, which could wind up in excess memory usage. So what JavaScript does is let you create a new object and link to the old original with an internal prototype property. This is NOT the public prototype property that you see on functions. This is an internal property that is not publicly accessible and is referred to in the spec as [Prototype]. Thus, if you try to access a property on a copied object, it will first look on the object itself, and if it does not find the property there, it will look on the object’s [Prototype]. If it’s not there, it will look on that object’s [Prototype] and so on up the chain until it reaches the top of the line, Object. If nothing on the chain has that property, it’s undefined for that object.
If that were the whole story, there wouldn’t be too much controversy on the subject. We’d create objects and create new objects based on them, and everyone would be happy. In fact, the Io Language, another prototype-based language, implements this very cleanly, and is a really fun language to program in. In it, you create a new object by cloning the base object, Object:
[php lang=”JavaScript”]person := Object clone[/php]
You assign properties to the new object:
[php lang=”JavaScript”]person name := “keith”[/php]
And then you can clone that object:
[php lang=”JavaScript”]evilTwin := person clone
evilTwin attitude := “bad”[/php]
The problem with JavaScript is twofold: It originally offered no simple, native way of cloning object like Io’s clone method, and it introduced the new operator and constructor functions. When I say “problem”, I mean problem in a sense that it detracted from and wound up confusing JavaScript’s prototype-based nature, in an attempt to make it look “kind of” like a class-based language.
No access to [Prototype]
Because JS’s internal [Prototype] property is not accessible, it was initially hard to create prototype-based clones. Some browsers have provided a __proto__ property which exposes [Prototype]. If this exists, you can achieve prototypical inheritance almost as simply as in Io, like so:
[php lang=”JavaScript”]var person = { name: “keith” };
var evilTwin = { attitude: “bad” };
evilTwin.__proto__ = person;
console.log( evilTwin.name ); // keith[/php]
You could make a clone function like so:
[php lang=”JavaScript”]function clone( parent ) {
var obj = {};
obj.__proto__ = parent;
return obj;
}
var person = { name: “keith” };
var evilTwin = clone( person );
console.log( evilTwin.name ); // keith[/php]
This will actually work if your browser supports the __proto__ property. Unfortunately, __proto__ is not a standard property and is not implemented in every browser. So that’s out.
The new operator and constructor functions
Instead of giving us a way to clone objects, JavaScript instead gave us the new operator and constructor functions. You know this already. It’s like this:
[php lang=”JavaScript”]function Person() {
this.name = “keith”;
}
var me = new Person();
console.log( me.name ); // keith[/php]
What actually happens when you use the new operator with a function? A few very interesting things.
First it creates a new object and runs the function using that object as “this”. Any assignments to this in the function get assigned to the newly created object.
Next, it looks at that function’s prototype property. This is the publicly accessible property that is called prototype, not the hidden [Prototype] or __proto__. All functions have this property. Whatever that property is, it is assigned as the new object’s [Prototype]. This allows us to put properties and methods on the function’s prototype that will become part of the objects’s [Prototype].
Finally, it returns that object. So now you can do something like this:
[php lang=”JavaScript”]function Person() {
this.name = “keith”;
}
Person.prototype.sayHello = function() {
console.log( “hello” );
}
var me = new Person();
me.sayHello(); // hello[/php]
None of this is new to you. The point is that there is no real magic going on here. We could duplicate this functionality as long as we have access to __proto__:
[php lang=”JavaScript”]function Person() {
this.name = “keith”;
}
Person.prototype.sayHello = function() {
console.log( “hello” );
};
var me = {};
Person.call( me );
me.__proto__ = Person.prototype;
me.sayHello(); // hello[/php]
Again, we’re creating an object, calling the constructor using that object as this, which we can accomplish with call (or apply). You could even pass arguments to that constructor:
[php lang=”JavaScript”]function Person( message ) {
this.name = “keith”;
this.message = message;
}
Person.prototype.sayHello = function() {
console.log( this.message );
};
var me = {};
Person.call( me, “yo, sup?” );
me.__proto__ = Person.prototype;
me.sayHello();[/php]
You could even create a function to make objects based on a constructor:
[php lang=”JavaScript”]function Person( message ) {
this.name = “keith”;
this.message = message;
}
Person.prototype.sayHello = function() {
console.log( this.message );
};
function create( constr ) {
var obj = {};
var args = Array.prototype.slice.call( arguments, 1 );
constr.apply( obj, args );
obj.__proto__ = constr.prototype;
return obj;
}
var me = create( Person, “awww yeah” );
me.sayHello();[/php]
Now, I’m not saying you should do this. In fact, I’ll reiterate that you absolutely shouldn’t. But it’s a fun exercise to see exactly what’s going on under the hood of new, and to fully understand that new is just sugar coating on top of JavaScript’s underlying prototype-based nature.
new and inheritance
The problem with this class-lookalike new operator becomes apparent when you start having one “class” inherit from another. The generally accepted solution is to create a new instance of the super “class” and assign it to the prototype of the new “class”.
[php lang=”JavaScript”]function Person( message ) {
this.name = “keith”;
this.message = message;
}
Person.prototype.sayHello = function() {
console.log( this.message );
};
function EvilTwin() {
}
EvilTwin.prototype = new Person( “muahahaha” );
EvilTwin.prototype.doBadStuff = function() {
console.log( “bad stuff is done” );
};
var twin = new EvilTwin();
twin.sayHello();
twin.doBadStuff();[/php]
This works fine, seemingly. The new object has the properties and methods from both “classes”. But various problems start to creep in. For one, notice that in what I’ve set up, there is no way to pass a message that will be used in the sayHello method when you are creating a new EvilTwin. In other words, there’s no automatic way of calling the super constructor. Also, if I overwrite a method, there is no way to call the super method. Various other problems arise based on the fact that constructor functions are not really classes at all, but some sleight of hand used to create prototype-based objects, as we’ve seen. Sure, people have gone about creating long complicated fixes for these issues that make JS look more and more like a class based language, but at what cost? I recently looked at one pseudo class library that was something like 1200 lines of code. All this complexity added no end user functionality whatsoever, only a way to make the programmer feel like he or she is using classes.
Object.create to the rescue!
As I’ve said, JavaScript has wound up with a confused identity due to it being a prototype-based language that had no way to create clones of existing objects (the core concept of prototype-based languages) and instead gave us a new operator to use with constructor functions to make it look more like a class-based language.
Fortunately, that is changing. ECMAScript 5 defines something called Object.create. This is essentially the clone method we created earlier. You pass it an object and it passes you back a new object that has the original one as its [Prototype].
[php lang=”JavaScript”]var person = { name: “keith” };
var me = Object.create( person );
var evilTwin = Object.create( me );
evilTwin.attitude = “bad”;
console.log( me.name ); // keith
console.log( me.attitude ); // undefined
console.log( evilTwin.name ); // keith
console.log( evilTwin.attitude ); // bad
[/php]
This is pure prototypal inheritance. Just like Io. Objects inheriting from other objects.
The good news is that many browsers already implement Object.create, so chances are you should be able to run that example right now. The other good news is that it’s easy to shim for those browsers that don’t have it:
[php lang=”JavaScript”]if( typeof Object.create !== “function” ) {
Object.create = function( obj ) {
function F() {}
F.prototype = obj;
return new F();
}
};[/php]
Since we cannot assign anything to an object’s [Prototype] (without __proto__), the only way of getting something in there is to assign it to a function’s prototype and then creating an object using new with that function. A bit of kludge, but it works, and with the above solution, you’ll get the native implementation if it exists.
Extending objects
Actually, the native version of Object.create is supposed to take an optional second parameter that is another object. All the properties on that object are copied over onto the new object. In the native version, this will be done with some new ECMA5 methods that deal with property attributes. So this can’t be exactly faked with environments that don’t have that. But you can create a method that extends an object by looping through another object and copying it’s properties. In fact, plenty of frameworks already have just such a function. But here’s a bare bones version:
[php lang=”JavaScript”]function extend( obj, props ) {
for( var prop in props ) {
obj[ prop ] = props[ prop ];
}
}[/php]
We can now redo our last example like so:
[php lang=”JavaScript”]var person = { name: “keith” };
var me = Object.create( person );
var evilTwin = Object.create( me );
extend( evilTwin, { attitude: “evil” } );
console.log( me.name ); // keith
console.log( me.attitude ); // undefined
console.log( evilTwin.name ); // keith
console.log( evilTwin.attitude ); // evil[/php]
Of course, for such a simple example, the extend function seems a waste, but if you were extending an object by adding some significant functionality, it would make it worth it.
Summary
I believe that going back to Object.create and treating JavaScript as the prototype-based language that it is will be a good thing. That’s 100% opinion. Not FACT. At any rate, it’s something that you should know about. I highly suggest you download the Io language and take a spin with it. In addition to the online documentation, there’s a chapter on Io in Seven Languages in Seven Weeks, which gives you a great intro to the language. Learning prototyped-base programming on a language you have no other experience with, and that implements it purely like Io is a great way learn the prototype way of doing things.
As always, don’t get serious about it. Learn some new stuff and have fun.
Further reading and Acknowledgments
I’d like to say I thought all this up myself, but of course it’s the distillation of lots of other stuff I’ve read over the past year.
http://javascript.crockford.com/prototypal.html
(Chapters 7 & 8 in particular)
And last but not least…
If you disagree with anything I say here, in the words of The Dude…
So in other words: they are the same thing but prototype is public static and __proto__ is private?
Also curious, when you say “there is no way to pass a message that will be used in the sayHello method when you are creating a new EvilTwin.” Is your evilTwin function technically a closure? (still trying to wrap my head around those bastids)
prototype only exists on functions and is copied to an object created when new is used with that object, to its [Prototype] which is hidden. Every object has a [Prototype] and it is exposed in some environments with __proto__
FACT: Hi ! (just kidding)
My tiny (<1KB) class system https://github.com/tekool/objs use the iteration you're talking about to copy properties from an object to rptotype of the other but need some exceptions for Internet Explorer. Some object methods are not enumerable on Internet Explorer. This give us what can be assumed as a little less bare bone but final version as it works everywhere :
—————————————————————–
function extend( func, protobject )
{
for( var propName in protobject )
if( protobject.hasOwnProperty(propName) )
func.prototype[propName] = protobject[propName];
//Some Object methods are not enumerable on Internet Explorer
func.prototype.toString = protobject.toString;
func.prototype.valueOf = protobject.valueOf;
func.prototype.toLocaleString = protobject.toLocaleString;
}
—————————————————————–
Also, that's too bad Internet Explorer supports Object.create only since IE9.
What a mess! So what the ‘universal’ convention to instantiate / inherit objects?
Sorry but I’m not convinced that JavaScript is a language for the future web.
Well, whether or not you are convinced, it’s there, it’s been there, it’s going to be there for a long time to come, and if anything, its use is very much on the rise.
Curious though, what do you think IS the language for the future web?
Something that has clear standards and structure, namespaces/modules, private/public accessors and whatever else every serious language has.
Hope that Google will push Dart hard enough and make the web better place for coders who deal with enterprise web apps or games other than casual simpletons.
JS is ok for simple stuff but it’s a joke for large scale web apps/games.
BTW, isn’t it funny that even Google wants to get rid of the JS?
@Dinko
Little curious about why you think Google wants to get rid of JS?
I like you do a lot of application development, lots of heavy data driven software in C# C++ etc
However I’ve recently been working with Google’s App Script for driving their sites and docs and for things like work flows and daily business needs and collaboration it is smooth and easy to write and use despite it being in it’s infancy.
Google’s App Script is nothing more than JS run in Google’s own cloud sand box with their own custom JS classes providing access to their other APIs
C# still is my favorite language to work with especially now that we have Linq and extension methods, however it is down right fun to work with JS because it is so light weight it’s very freeing in some ways
Also JS lends itself more to web based interactive applications.
I mean just look back at how far we’ve come from the days of CGI and SOAP with the need for compiled server code, or the bloated but standardized ways to transmit information and logic across the web. Think of how bloated the viewstate gets in ASP.NET projects (That’s why eve MS moved towards the MVC framework that HEAVILY relies on JQuery and other javascript functionality to not only simplify the process of creating but empowers you as a developer to create exactly what you want.)
Now we’ve got JSON that is nothing more than leveraging how JS already treats it’s objects natively and adding a little bit of sanitation, The most extra bits (in the form of characters you get is 4 ” and a : for each property, value pair) then comma’s for seperators and an opening and closing {} or [] for objects and arrays. There really is no way to get a more concise data bundle while still retaining the object structure and property names than with JSON, all of which is possible because of JS.
The biggest reason I think JS gets such a bad wrap is for years we’ve been trying to use it as the quintessential “Crescent Hammer” When you start letting the different technologies that make up the Web do what they do best and stop trying to force them to be something else it makes life so much happier and fun.
But that’s just my opinion.
You know, when I write about ActionScript, people come on and comment about how Flash sucks. When I write about Objective-C, people comment how much they hate it and it’s has horrible confusing syntax. When I write about JavaScript, lo and behold, I get a stream of comments about how much JavaScript sucks and can’t be used for anything serious (despite obvious evidence to the contrary). I think my main problem is that I continue to take these comments seriously.
It’s a bit of a shame you have to write defensively to ward off zealous finger pointers. Nonetheless, I’m glad it doesn’t bother you so much that it keeps you from writing posts like these.
Heh, I can understand your frustrations but try not to take the comments seriously.
They are just people’s opinions. Someone like this and someone like that.
I’m just talking about from my perspective since I’m doing large scale software day to day and JS for stuff like that compared to c#, c++, obj-C, AS3, haxe etc. looks and feels terrible.
Anyway, keep writing, you are doing a good job.
Best,
D.
Hi Keith,
Thanks to your inspiration, I’ve gotten a few books from the library and installed WebStorm, and I’m slogging my way through learning some JavaScript. But I have to agree with the comment above that it’s really disheartening to work with a language that seems so disjointed. One of the amazing things about Flash is that stuff I made 10 years ago still works exactly the same on every browser and every version of Flash. I keep reading JS tutorials and half the comments are about “hey this doesn’t work on my browser”. Is that what I have in store? 20 days of QA on a 20 day project? Also, I do almost exclusively games, and with Flash 11 and Away3D I’m making some pretty impressive visual stuff, but clients with iPads are asking about JS games instead? I feel like I’m back with AS1, debating the merits of sub-100kb websites.
In answer to your question, I don’t know the future, but I hope JS is somehow improved to be a real language or something better comes along soon.
Thanks for the post, though.
Not sure why AS3 is coming back on a JS post but… I think the frustration is coming from the fact that AS developer learned how to write code in their own language with classes, good practices, design pattern, and so on.
And as that does not apply directly on JS, you must feel that all these things you learned and are not in used directly in JS makes you go backward.
For good or bad, I think you just just have to take things how they are.
At least that’s how I sometimes feel. For the JS matter, Mootools did remove some of my frustrations as its class system looks very close to AS and Java.
My own answer to Keith on his previous post: “You can create structures in JavaScript that emulate classes. Yes, but should you? That’s today’s topic.”
My own answer to that (and it is very personal) is yes you can do that and it is not a problem at all. Especially if that removes some of the frustrations you might have and if that make you like what you are doing 🙂 Which is for me quite important.
Post very appreciated in any case.
Stating ‘FACT’ on the intertubes is a bit asking for trouble, especially in geek-territory :p
I’m starting to wrap my head around Object.create (and the 3 [prototype], .prototype, __proto__ things). With the constructor-way there would be objects that are dedicated prototypes (the code part bit where we do the ConstructFunc.prototype.method = … ; and regular ‘instances’ (created with new).
But because you could use ANY object as prototype it’s also like the ultimate ‘default-value’ chain, it’s a cascade! (like CSS 🙂
You could make objects that are like poly-compound-object’s by chaining their proto’s, and by keeping references to each step you could switch at which level you access it (and so which step in the cascade the prototype starts resolving).
Oh wow.. mhuwuwuwHAHA! The power! (evil laugh) The powerr!
Thanks 🙂
Hi keith, excellent article and thanks for the effort to write it. Some comments about this “Also, if I overwrite a method, there is no way to call the super method.” You can call it by invoking the method of the prototype of the ‘base class’, something like this:
MyClass.prototype.method1 = function(arg1){
BaseClass.prototype.method1.call(this, arg1);
}
I guess you know that but anyway I wanted to write it … 🙂
Thanks. I guess I should have said there is no easy or obvious way to call it. 🙂
Stopped trying to use ‘ traditional’ classes in javascript for a few days after I got some inspiration from this video: http://vimeo.com/34522837 I prolly misunderstood a lot but since I mostly pass around objects with data or json it would make sense to extend and/or clone them and add functionality instead of forcing them into a traditional class. Your blog post helped to show a few different techniques I could use so thank you!
Your pitch for Object.create() is:
1. The prototype/new approach has problems because there’s no “automatic” way to call super() or super.method().
2. Object.create() to the rescue!
3. ??
How does Object.create() address the dreaded problems that are apparently enough to sink the first approach?
I’m not saying that the problem with new is not that there is no automatic way to call super. That’s an awfully condensed version of what I said. The problem with new (as I see it) is that it attempts to make JavaScript look like it has classes. And when you have classes, you expect them to work in a certain way. And because they don’t, people start piling on complexity to make the non-classes look and behave more like classes and never quite get there.
Object.create does not solve super. Object.create lays aside the complexity so you can see what you are really doing.
I also never said that they they were dreaded problems that sink the approach. Come on man! Read the whole post, don’t just skim for parts you disagree with! 🙂
Keith,
I admit I had some “commenter’s remorse” shortly after posting. It’s a bit of an inflammatory straw man, my apologies.
Believe me though, in the last day I’ve read this post and your new Adobe Devnet article several times, along with the Douglas Crockford link, Mozilla’s docs page for Object.create() and a couple other articles on Javascript inheritance.
If I may take another stab at this–
The first half of your article is an excellent summary of traditional JavaScript prototype inheritance. Clear code examples and I appreciated the __proto__ discussion, which is especially helpful for readers with ActionScript 1 experience.
However, I think the paragraph before “Object.create() to the rescue!” is a weak argument. This is the critical juncture where the reader is supposed to see how Object.create() solves problems arising from the previous approach, which you said seemingly works fine, apart from the following:
1. Can’t call super constructor
2. Can’t call super method
3. “Various other problems” caused by JavaScript quirks
4. People try to fix said problems and implement pseudo classes but at the cost of extra code.
5. One pseudo class library has 1200 lines of code that adds no end user functionality
#1 and #2 are problems no matter which approach you choose.
#3 doesn’t elaborate on the symptoms of the other problems.
#4 doesn’t help me evaluate the cost-benefit of the extra code.
#5 makes a claim about a unnamed straw man.
If readers are trying to decide whether they should switch from pseudo-classes to this Object.create() style, more specifics would be helpful.
OK, the “to the rescue” bit was supposed to be a bit tongue in cheek. Again, if you read the whole post, you’ll see things like this:
“in the aforementioned post, I said that there were other, possibly … “better” ways of reusing code in JavaScript than by emulating classes. Take that “better” with a grain of salt. There are other ways, and some consider them better.”
and this:
“I believe that going back to Object.create and treating JavaScript as the prototype-based language that it is will be a good thing. That’s 100% opinion. Not FACT. At any rate, it’s something that you should know about.”
A bit more…
My point of this post was not to beat up classical (new with constuctors) inheritance. It was also not how to handle calling of super methods.
If you are interested in knowing all the problems and drawbacks with classical inheritance and why direct prototypal inheritance MAY be “better”, I recommend Chapter 6 of the OReilly JavaScript Patterns book. In 15 pages, the author goes through 6 different attempts at creating pseudo classes, detailing the pros and cons of each.
Also, Test Driven JavaScript Development, Chapter 7 goes through a lot of the same material, with a lot of attention on dealing with super.