OO JS in 15mins or Less
beardedocto.tumblr.com
beardedocto.tumblr.com
And in the code, there is only one instance. No copying has taken place, but there are two references to the same object.
In the example above we create a new variable sally, and assign it the value bill. Both sally and bill reference the same spot in memory. As such we can't change bill out w/ out changing Sally, specifically when a change is made to an object literal it will affect that object across the entire script.
How about: In the example above we create a new variable sally, and make it equal to bill. Both sally and bill now reference the same object in memory. Changes made via one affect both of them.
Specifically the sayName function was created in the global scope, so when it came across the statement this.name it looks in the global scope for the value of name.
It doesn't matter where a function is created, but it matters how it's called. A pretty simple example is that typing sayHello() by itself desugars to sayHello.call(window);, where window is the global scope[1]. JavaScript function invocation is fairly confusing until you learn the rules.
I also really liked Yehuda's JS prototypes article[2]. It really helped me understand them.
[1]: Except in JS strict mode apparently? I don't know too much about that. See http://yehudakatz.com/2011/08/11/understanding-javascript-fu...
[2]: http://yehudakatz.com/2011/08/12/understanding-prototypes-in...
I think that it is far better than this article.
This is the correct approach.
...not because those operators are bad, but because they _are_ confusing, and will confuse some people who work on the code base. Simple javascript is elegant and maintainable.
I feel like in any overview of JavaScript you HAVE to mention two things: 1) constructors aren't classes, they're non-magical functions (it's the "new" keyword that actually does the magic) and 2) inheritance works through a prototype chain, not through a class chain. Once you understand these two things (which will blow your mind) the rest is easy. (EDIT: okay, then there what "this" does in different contexts, but that's details)
This article is pretty elucidating: http://livingmachines.net/2009/02/creating-javascript-classe...
Please take your time to understand how things really work, it will pay off in the future. A good starting point is http://killdream.github.com/blog/2011/10/understanding-javas...
In JS, this reflects the context of the caller, not the object (which I think is messed up), so you have to learn call and apply.
var a = {fn : function () {this.doStuff()}},
b = {};
b.method = a.fn;// What now?
Another viable solution would be to have `this` passed into a method explicitly, like in Python. Then the expression `a.b()` could desugar to something like `a.b(a)` with `b` expecting `this` as its first argument. This also has some disadvantages. You could also do like Lua and have a separate syntax for calling methods this way (a:b()), but this is also confusing.
In short, there is no perfect solution.
Game.prototype.heartIt = function() {
console.log( "I heart " + this.title );
};
Love it when they don't just tell you how to do something. Would like to see more people write on when you should use something.
Or why. None of the examples seem like constructors provide any advantage over literals.
function getObject(val1, val2) {
return {
foo: val1,
bar: function() {
return val2;
}
};
} bill.sound = function(noise) {
console.log( sound ); // should be console.log(noise)
}