6 ms·

OO JS in 15mins or Less

122 points by mdgrech23 14y ago

jmaicher 14y ago
There is no zelda.prototype. It should have been: Game.prototype.heartIt = function() { console.log( "I heart " + this.title ); }; See: http://jsfiddle.net/a9asJ/1/ http://jsfiddle.net/a9asJ/1/
- mdgrech23 14y ago
  Thank you, corrected!
president 14y ago
"Constructor notation is preferred when you need to set initial properties and methods on an object or you plan on creating multiple instances of an object where the properties and methods of each instance need to be unique." 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.
- recursive 14y ago
  > Love it when they don't just tell you how to do something. Or why. None of the examples seem like constructors provide any advantage over literals.
  - ww520 14y ago
    So that the methods don't need to be re-defined for every object.
    - recursive 14y ago
      Object literals don't require you to duplicate any code: function getObject(val1, val2) { return { foo: val1, bar: function() { return val2; } }; }
      - stephenr 14y ago
        In this instance the "bar" method is redefined every time you call getObject.
joubert 14y ago
Folks might also be interested in this article on implementing other common design patterns in JavaScript － http://addyosmani.com/resources/essentialjsdesignpatterns/book/#modulepatternjavascript http://addyosmani.com/resources/essentialjsdesignpatterns/bo...
- mdgrech23 14y ago
  Agreed, everything Addy does is amazing.
- loeschg 14y ago
  Thanks, I found this section from Addy on constructors helpful as well (to clear up some prototype confusion). http://addyosmani.com/resources/essentialjsdesignpatterns/book/#constructorpatternjavascript http://addyosmani.com/resources/essentialjsdesignpatterns/bo...
SideburnsOfDoom 14y ago
The text is quite misleading. Where it says "When using Object literals, if we copy an object and change a property or a method that method/property will be changed for all instances." And in the code, there is only one instance. No copying has taken place, but there are two references to the same object.
- dgreensp 14y ago
  Agreed, anyone who uses this as the beginner tutorial it is will be confused for a long time by words like "copy" and "clone" used to mean variable assignment. This is terrible teaching, or somehow the author has an exotic mental model of what the computer is doing.
- mdgrech23 14y ago
  Agreed. I could see how that line could be confusing. Why don't we change it for the better in that case? How about something like this: 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.
  - SideburnsOfDoom 14y ago
    Something like that would be right. 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.
    - mdgrech23 14y ago
      Awesome, you rock! Officially updated the post w/ the above :)
  - SideburnsOfDoom 14y ago
    Today I learned that in ECMAScript5 (IE 9 onwards) there is also a function called Object.Create ( https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Object/create https://developer.mozilla.org/en/JavaScript/Reference/Global... ) which can be used to copy objects. Kinda.
VMG 14y ago
small correction: bill.sound = function(noise) { console.log( sound ); // should be console.log(noise) }
- mdgrech23 14y ago
  Good call, I just updated it. Thanks!
sarenji 14y ago
A small nit: 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-function-invocation-and-this/ http://yehudakatz.com/2011/08/11/understanding-javascript-fu... [2]: http://yehudakatz.com/2011/08/12/understanding-prototypes-in-javascript/ http://yehudakatz.com/2011/08/12/understanding-prototypes-in...
Porter_423 14y ago
prototype is a property on all Javascript objects which refers to the "constructor" of the current object. So since zelda is a new Game(), zelda.prototype = Game. When you modify an object in JS, all objects that refer to that object as a prototype will inherit those changes immediately. Since zelda and smb both inherit from Game, any changes to either of their prototype properties are actually changes to Game, and will immediately effect both zelda and smb.
ww520 14y ago
This is a very good intro to JS OO. Keep up the good work.
- mdgrech23 14y ago
  Thank you! I cleaned up the issues noted here and in the comments. I'd like to create another post on inheritance or digging into prototype as well :)
jseims 14y ago
An OO JS tutorial should also include a discussion of the this pointer, and how it's not like other OO languages. 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.
- mdgrech23 14y ago
  My first thought here was holy cow yes it should! My second though was ack, there's a lot to go over. Sounds like a good topic to cover in a second post. However if you see a way to nicely integrate into the current post in brevity I'm all ears and would be happy to update the post :) Thanks!
- tikhonj 14y ago
  The problem is that in JavaScript functions (and, consequently, methods) are first-class citizens. If `this` reflected the value of the object, certain code would work oddly: var a = {fn : function () {this.doStuff()}}, b = {}; b.method = a.fn;// What now? So what JavaScript did actually makes some sense. 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.
jarek-foksa 14y ago
This is yet another article on JS OOP that jumps straight to constructors without explaining the fundamental concepts of prototypical inheritance. 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-javascript-oop/ http://killdream.github.com/blog/2011/10/understanding-javas...
aurelianito 14y ago
A few days ago this guide appeared here in Hacker News: http://www.gabordemooij.com/articles/jsoop.html http://www.gabordemooij.com/articles/jsoop.html I think that it is far better than this article.
- shadowmint 14y ago
  yes. quote: "Note that we did not use a lot of confusing JS stuff: no this, no new, no prototype. Therefore this approach is not only easy, minimalist and elegant but it also works in the most ancient and exotic browsers." 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.
base698 14y ago
(> fn OO)
- olliesaunders 14y ago
  I think you mean FP. And I agree with you.
mcmire 14y ago
This is okay, but you talk about "cloning" objects by giving them a different variable name, then you talk about constructors, and then you VERY briefly mention the "prototype" property -- which is actually the secret behind it all. 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-classes-part-1-with-screencast/ http://livingmachines.net/2009/02/creating-javascript-classe...
edfuh 14y ago
What about inheritance?

122 points by mdgrech23 14y ago

There is no zelda.prototype. It should have been: Game.prototype.heartIt = function() { console.log( "I heart " + this.title ); }; See: http://jsfiddle.net/a9asJ/1/ http://jsfiddle.net/a9asJ/1/

mdgrech23 14y ago
Thank you, corrected!

president 14y ago

"Constructor notation is preferred when you need to set initial properties and methods on an object or you plan on creating multiple instances of an object where the properties and methods of each instance need to be unique." 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.

recursive 14y ago
> Love it when they don't just tell you how to do something. Or why. None of the examples seem like constructors provide any advantage over literals.
- ww520 14y ago
  So that the methods don't need to be re-defined for every object.
  - recursive 14y ago
    Object literals don't require you to duplicate any code: function getObject(val1, val2) { return { foo: val1, bar: function() { return val2; } }; }
    - stephenr 14y ago
      In this instance the "bar" method is redefined every time you call getObject.

joubert 14y ago

Folks might also be interested in this article on implementing other common design patterns in JavaScript － http://addyosmani.com/resources/essentialjsdesignpatterns/book/#modulepatternjavascript http://addyosmani.com/resources/essentialjsdesignpatterns/bo...

mdgrech23 14y ago
Agreed, everything Addy does is amazing.
loeschg 14y ago
Thanks, I found this section from Addy on constructors helpful as well (to clear up some prototype confusion). http://addyosmani.com/resources/essentialjsdesignpatterns/book/#constructorpatternjavascript http://addyosmani.com/resources/essentialjsdesignpatterns/bo...

SideburnsOfDoom 14y ago

The text is quite misleading. Where it says "When using Object literals, if we copy an object and change a property or a method that method/property will be changed for all instances." And in the code, there is only one instance. No copying has taken place, but there are two references to the same object.

dgreensp 14y ago
Agreed, anyone who uses this as the beginner tutorial it is will be confused for a long time by words like "copy" and "clone" used to mean variable assignment. This is terrible teaching, or somehow the author has an exotic mental model of what the computer is doing.
mdgrech23 14y ago
Agreed. I could see how that line could be confusing. Why don't we change it for the better in that case? How about something like this: 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.
- SideburnsOfDoom 14y ago
  Something like that would be right. 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.
  - mdgrech23 14y ago
    Awesome, you rock! Officially updated the post w/ the above :)
- SideburnsOfDoom 14y ago
  Today I learned that in ECMAScript5 (IE 9 onwards) there is also a function called Object.Create ( https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Object/create https://developer.mozilla.org/en/JavaScript/Reference/Global... ) which can be used to copy objects. Kinda.

VMG 14y ago

small correction: bill.sound = function(noise) { console.log( sound ); // should be console.log(noise) }

mdgrech23 14y ago
Good call, I just updated it. Thanks!

sarenji 14y ago

A small nit: 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-function-invocation-and-this/ http://yehudakatz.com/2011/08/11/understanding-javascript-fu... [2]: http://yehudakatz.com/2011/08/12/understanding-prototypes-in-javascript/ http://yehudakatz.com/2011/08/12/understanding-prototypes-in...

Porter_423 14y ago

prototype is a property on all Javascript objects which refers to the "constructor" of the current object. So since zelda is a new Game(), zelda.prototype = Game. When you modify an object in JS, all objects that refer to that object as a prototype will inherit those changes immediately. Since zelda and smb both inherit from Game, any changes to either of their prototype properties are actually changes to Game, and will immediately effect both zelda and smb.

ww520 14y ago

This is a very good intro to JS OO. Keep up the good work.

mdgrech23 14y ago
Thank you! I cleaned up the issues noted here and in the comments. I'd like to create another post on inheritance or digging into prototype as well :)

jseims 14y ago

An OO JS tutorial should also include a discussion of the this pointer, and how it's not like other OO languages. 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.

mdgrech23 14y ago
My first thought here was holy cow yes it should! My second though was ack, there's a lot to go over. Sounds like a good topic to cover in a second post. However if you see a way to nicely integrate into the current post in brevity I'm all ears and would be happy to update the post :) Thanks!
tikhonj 14y ago
The problem is that in JavaScript functions (and, consequently, methods) are first-class citizens. If `this` reflected the value of the object, certain code would work oddly: var a = {fn : function () {this.doStuff()}}, b = {}; b.method = a.fn;// What now? So what JavaScript did actually makes some sense. 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.

jarek-foksa 14y ago

This is yet another article on JS OOP that jumps straight to constructors without explaining the fundamental concepts of prototypical inheritance. 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-javascript-oop/ http://killdream.github.com/blog/2011/10/understanding-javas...

aurelianito 14y ago

A few days ago this guide appeared here in Hacker News: http://www.gabordemooij.com/articles/jsoop.html http://www.gabordemooij.com/articles/jsoop.html I think that it is far better than this article.

shadowmint 14y ago
yes. quote: "Note that we did not use a lot of confusing JS stuff: no this, no new, no prototype. Therefore this approach is not only easy, minimalist and elegant but it also works in the most ancient and exotic browsers." 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.

base698 14y ago

(> fn OO)

olliesaunders 14y ago
I think you mean FP. And I agree with you.

mcmire 14y ago

This is okay, but you talk about "cloning" objects by giving them a different variable name, then you talk about constructors, and then you VERY briefly mention the "prototype" property -- which is actually the secret behind it all. 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-classes-part-1-with-screencast/ http://livingmachines.net/2009/02/creating-javascript-classe...

edfuh 14y ago

What about inheritance?