7 ms·

Javascript Constructors and Prototypes

52 points by nccong 13y ago

gregorkas 13y ago
I wanted to read this because I believe it's a great article, but the fact that he doesn't use semicolons pretty much turned me off. While I was looking at the JavaScript code my brain almost exploded.
- pests 13y ago
  Did you see the article he linked about why he doesn't use them? http://mislav.uniqpath.com/2010/05/semicolons/ http://mislav.uniqpath.com/2010/05/semicolons/ Not reading an article because of that would be like not reading other code because it uses 2 spaces for tabs instead of 4. Makes no difference to the language, only to you.
  - wldlyinaccurate 13y ago
    The thing is, semicolons do make a difference with JavaScript. It's now 404ing, but there was a pretty well-known argument on one of Twitter Bootstrap's GitHub issues[1]. The Bootstrap guys didn't use semicolons, and it caused problems when minifying the code. It's an edge case, I know, but it was a problem. I never understood the whole anti-semicolon thing anyway. It just seems really hipster to me. Use CoffeeScript, if you don't want semicolons. [1] https://github.com/twitter/bootstrap/issues/3057
    - tg3 13y ago
      If it caused problems when minifying the code, the problem was with the minifier not parsing correctly - a minifier shouldn't change the way the code is interpreted. I understand that using existing minifiers is a possible reason to use semicolons, but not using semicolons is not an inherent issue here.
    - ealexhudson 13y ago
      It shouldn't, they genuinely are optional, and Javascript coders need to know when they can be inserted because you can't turn that behaviour off. However, needing to understand the rules is one thing - I much prefer to see the semi-colons in there. I dislike seeing any formatting that is substantially different from the accepted norm and find it harms readability.
    - marrs 13y ago
      Why does it seem hipster to use a language feature? Is it hipster to use null coalesce as well? The article linked above explains the reasons to omit semi-colons very well. I would personally prefer if JS forced you to terminate all statements with a semi-colon to avoid any ambiguity, but there you go. Speaking of ambiguity caused by whitespace, Coffeescript is a 1st degree offender for this. All you have to do is indent the wrong block of code, and you completely change the scope of a nested function, and you have no visual indication of your mistake whatsoever.
      - mradmin 13y ago
        It's hipster because it goes against the accepted standard way of writing Javascript. See https://news.ycombinator.com/item?id=1547647&utm_source=twitterfeed&utm_medium=twitter https://news.ycombinator.com/item?id=1547647&utm_source=twit...
        marrs 13y ago
        My interpretation of "hipster" is being different because you think it's cool to be different. Being different because you think it's a better approach is called "making progress", either because you'll be proven right or proven wrong. I've thought about the de-facto standard way a lot and I think that it does nothing to avoid bugs while potentially misleading a coder about the language. Therefore I think it's worse. The only reason I follow the de-facto standard is because the time spent arguing about it with my peers is better spent getting work done.
        andypants 13y ago
        Nobody has any good reasons that apply to most people, both for and against semicolons. There really isn't a huge difference in either style except in rare cases. > The only reason I follow the de-facto standard is because the time spent arguing about it with my peers is better spent getting work done. Which is why that is an excellent reason. Standards are useful, so if there is one, stick to it. If there is no reason to go against the standard, then don't. > I think that it does nothing to avoid bugs while potentially misleading a coder about the language. Therefore I think it's worse. Not seeing any semicolons can also potentially mislead about the language. It is not worse, they are both misleading until you realise ASI exists. Omitting semicolons also does nothing to avoid bugs, and introduces a different (additional?) set of edge cases where bugs may appear.
    - jalfresi 13y ago
      I've always equated javascript without semi-colons with missing comments and poor commit messages. It's just inconsiderate to other developers who have to read your code. I understand that it is a "feature" of javascript (misfeature in my opinion), but the point that "everyone else does it is not a good argument" is false. We've got like 15 years of javascript written with semicolons. Stop being an inconsiderate prick and just friggin write the code like everyone else! Don't be that guy (or gal). Comment your code. Write good commit messages. Use semicolons in your javascript.
    - testing12341234 13y ago
      The link to the issue you mention is broken because the bootstrap repository moved from twitter to twbs. The new link is https://github.com/twbs/bootstrap/issues/3057 https://github.com/twbs/bootstrap/issues/3057. Also note, that ultimately regardless of personal semicolon preference, this was an issue because of a parsing bug in JSMin. It was fixed in JSMin with this commit[0]. Other minifiers such as Closure and YUI did not exhibit any issues with the code as it had been written. [0] https://github.com/douglascrockford/JSMin/commit/5ca277ea452beae1c25db3bc0ef5c81309a3daf4 https://github.com/douglascrockford/JSMin/commit/5ca277ea452...
  - wrboyce 13y ago
    The article (justifying not using semicolons) seems like a rant with not real aim, beside "I am right, semicolons are wrong - and I have all these half-baked ideas to back me up". The author was actually annoying me by the time I reached "It's good coding style". One example: > My advice on JSLint: don’t use it. Why would you use it? If you believed that it helps you have less bugs in your code, here’s a newsflash; only people can detect and solve software bugs, not tools. So instead of tools, get more people to look at your code. Pretty sure lots of people use JSLint, pep8 checkers, gofmt, or whatever the equivalent tool for the language at hand is. They certainly help, one cannot deny that. Then the author goes on to pick at Crockford for suggesting people space their JS with four spaces… Yep, I'm done.
    - martin-adams 13y ago
      Giving advice to not use JSLint without a real alternative is very naive in my opinion. When I was working with a team of developers with some novice JS developers, JSLint was a godsend to pick up simple, avoidable bugs while enforcing some sanity with regards to code style.
    - andypants 13y ago
      > only people can detect and solve software bugs, not tools Stupid compilers, they've been doing it wrong this whole time.
  - stefanve 13y ago
    Maybe it is not necessary but I don't see anything against it. That was the weird thing about that article all kinds of semi legit reasons why it is not necessary to use them but no reason why not to use them. I would say if there are some semi legit reasons to use them and no reason not to use them than just use them :)
  - gregorkas 13y ago
    I agree with you, but still, I look at (a lot of) JavaScript every day and it's hard to explain it, but for some reason I find the lack of semicolons disturbing. I have no problem with CoffeeScript and I've also worked with Python a lot so I appreciate a language without semicolons, but I don't approve mixing the styles. I think this is more of a psychological thing than a syntax thing because if you're used to a syntax of a language, it gets embedded in your brain and with years of practice you can spot a missing semicolon from a mile away after only a quick glance over the code. People are afraid of changes and if they are used to something and that thing is taken away they become unsettled. Or their brain explodes if they see JavaScript with missing semicolons :P.
  - Donito 13y ago
    Terrible article in my opinion teaching some really bad habits that will cause hard to find bugs over time. Truth is, omitting semi-colons is probably fine at smaller scale, but for larger javascript code base with multiple maintainers, it's definitely a better practice in my opinion. Oh well, no point in me saying what has already been said :)
  - coldtea 13y ago
    >Did you see the article he linked about why he doesn't use them? Yes, it's bollocks, goes against standard practice, and abuses a misfeature of the JS interpreter.
  - nhebb 13y ago
    I defer to Brendan Eich on the matter: https://brendaneich.com/2012/04/the-infernal-semicolon/ https://brendaneich.com/2012/04/the-infernal-semicolon/
- wwweston 13y ago
  I totally understand the preference for using explicit statement termination in JS. I can even understand the general preference for a non-whitespace token to terminate a statement. But I don't understand why that would cause someone's brain to explode or otherwise make it difficult for them to pick out the author's points about the language from the example code.
M4v3R 13y ago
I used the prototype mechanism several times when debugging a script that I couldn't easily change source code for. I just typed: SomeClass.prototype.someMethod Which outputs the methods source. Then you can add some debug code like console.log(xxx) or even fix a simple bug, copy the whole thing and set it again: SomeClass.prototype.someMethod = function ... Voila! Hot code push without an IDE. While that's obviously not ideal, it certainly works in some cases.
- nccong 13y ago
  Good point. It's a quick way to debug/experiment.
- GeneralMayhem 13y ago
  My favorite trick along those lines: var cache = SomeClass.prototype.someMethod; SomeClass.prototype.someMethod = function () { debugger; // or `throw "stacktrace"` cache.apply(this, arguments) } Inserts a stack trace right in the middle of executing someone else's code, which is nice for tracking down why/when that function gets called if documentation is poor, without changing functionality.
kybernetikos 13y ago
I wrote an interactive guide to javascript that covers a lot of the same material. http://caplin.github.io/new2JS/ http://caplin.github.io/new2JS/
- stefanve 13y ago
  Looks nice and it helpful, thanks. Maybe you could change the output so the latest output is on top instead on the bottom (more blog style). Also it would be nice to reset the output altogether
alexdf 13y ago
>>Cat.prototype = new Mammal() This is only useful if Mamaml has only methods and no properties which does not happen that often. >> Cat.prototype.constructor = Cat I never saw a practical usage of this one :-) I think these days the standard way of doing inheritance should be -> MyClass.prototype = Object.create(baseClass.prototype)
aleclarsoniv 13y ago
If the arguments you wanted to pass to a constructor were variable in length, why not just send them in an array normally instead of having to jury-rig this? Are there benefits I'm missing?
itsbits 13y ago
oh God!! why do some people have problem with adding semicolon?
warbastard 13y ago
It's breathe not breath...
GeneralMayhem 13y ago
This article does two things that are very dangerous, and never mentions the reasons why they're dangerous. * Messing with Function's prototype is very strongly frowned upon. It's tantamount to setting global variables. At the very least, give that definition an if (!Function.new) guard to prevent redefining another implementation that another script (or the browser!) has already given. * Adding methods in the constructor is awful even if you're not using inheritance, because it burns memory like crazy. If you define sayHi on Person.prototype, then every Person gets a reference to the same sayHi method. If you define this.sayHi in the constructor, then each Person you create gets its own copy of the function, making every Person heavier in memory. Not a big deal for a simple console.log, but if you have more complicated objects with a few dozen methods that you're using a bunch of you can really make things chug.
- mdigi 13y ago
  "In the first version, each time you create a person, a new sayHi function will be created for him, where as in the second version, only one sayHi function is ever created, and is shared amongst all persons that are created - because Person.prototype is their parent. Thus, declaring methods on the prototype is more memory efficient."
  - GeneralMayhem 13y ago
    Ah, you're right, I missed that. Small amount of bile revoked. But it should have been MUCH more strongly emphasized as the only way to do it, unless you have a very good reason, not tucked down in the bottom as "oh, if you feel like it, here's a trick to make your code a little better." Especially in a tutorial that's meant for beginners in JS.
- esailija 13y ago
  Since this is usually downplayed because the "code is shared", to be more specific, for example in V8 in x64 (node.js, Google Chrome), the theoretical minimum memory used by a function object is 72 bytes: - Map pointer: 8 - Properties pointer: 8 - Elements pointer: 8 - Code entry pointer: 8 - Initial Map/prototype pointer: 8 - SharedFunctionInfo pointer: 8 - Context pointer: 8 - Literals/Bindings pointer: 8 - Weak fields pointer: 8 So if you have a Person class with 30 methods, the methods are taking 30 * 72 = 2160 bytes at the very least. The actual data for a person might take 200 bytes, if we store e.g. full name, age and address so in this case there is like 10x overhead. If you print the details of 200 people per page request and there are 100 people connecting to your server, you are wasting 200 * 100 * 2160 =~ 40 megabytes on memory on storing all these useless function objects at that moment. That is just crazy. And in GC language it's never just memory, a GC will eat exponentinally more CPU time when the amount of memory you use reaches closer and closer to limits.
drunken_thor 13y ago
The article could have addressed overriding methods and calling the super method. Because that isn't simple.
raju 13y ago
I wrote a similar (2 series) article a while back that attempts to explain the same thing, but with a few diagrams. I know sketching out what was going on really helped me ... http://www.looselytyped.com/blog/2012/08/18/on-prototypal-inheritance/ http://www.looselytyped.com/blog/2012/08/18/on-prototypal-in... http://www.looselytyped.com/blog/2012/08/22/on-prototypal-inheritance-part-ii/ http://www.looselytyped.com/blog/2012/08/22/on-prototypal-in...
deleted 13y ago
[deleted]
acjohnson55 13y ago
I'm bracing for the downvote, but I'm going to say this anyway: are we all taking crazy pills? I understand that we're more or less stuck with JavaScript, but this is nuts. JS has got to be one of the least intuitive, cobbled together languages I've ever had to work with. In what other language are people still having holy wars over how to separate statements? Why the heck would a constructor be a regular function if calling it without new pollutes the global namespace? JS gives us prototypes so that we can have inheritance! Great, but that doesn't actually give us a simple ability to call super. Using functions as everything is fine and good, until you have to shoehorn all the functionality you actually need into mysterious constructs like prototype, new, and apply. When the symmetries are so half-assed, at some point, it seems to me to make way more since to stop overloading the same language construct and make separate constructs for separate uses. And don't even get me started on implicit variable declaration, function hoisting, the double-equals, for...in, the necessity of self-calling functions, etc. Thank God we have libraries and alternative syntaxes now that more or less smooth over these issues and coerce the programmer into writing reasonable JS code, because green field JS is a complete quagmire. Are we seriously incapable of doing better?
- wwweston 13y ago
  > In what other language are people still having holy wars over how to separate statements? Probably most of the languages in popular use. It's just that the fight is usually directed towards another language. JS happens to be one of the minority where the standard allows some flexibility and debate about usage. > mysterious constructs like prototype, new, and apply They're well-defined, so they're not particularly mysterious if you take the time. > Are we seriously incapable of doing better? Really depends on how much effort you're willing to invest in learning JavaScript, instead of trying to write the code you're used to from $OTHER_OO_LANGUAGE. Everyone unwilling to do that is probably never going to be capable of doing better. This isn't to say there's anything wrong with finding another familiar set of abstractions friendly or personally productive, but personally, I find greenfield JS is pretty fun, flexible, and capable. Then again, I think the same thing about Perl (which everyone knows is one of the worst languages ever), so YMMV.
  - 13y ago
wwweston 13y ago
"Someone pointed out though, that you can prevent this polluting of the namespace (those are just big words for creating global variables) by using this trick: function Person(name){ if (!(this instanceof Person)) return new Person(name) this.name = name }" This is useful for situations where you might want to be able to create anonymous objects and call a series of methods on them, which can be a nice API as any user of jQuery knows. It's also an arguably cleaner way of achieving the constructor+apply thing he does later -- no global modification of the Function prototype. A lot of the time, though, I'll just consider this my default "class" definition: function Person (args) { this.init(args); } If you want to be warned (or want others to be warned) when Person is called w/o new, this will do it (unless someone has defined init on the global namespace, so avoid that). This also makes it easier to hand around the method that does the actual construction, which is helpful for cases like constructor + apply: var p = new Person; p.init.apply(p,args); (again, without global modification of the Function prototype) or for cases where you want to refer to "superclass" methods down an inheritance hierarchy.

52 points by nccong 13y ago

I wanted to read this because I believe it's a great article, but the fact that he doesn't use semicolons pretty much turned me off. While I was looking at the JavaScript code my brain almost exploded.

pests 13y ago
Did you see the article he linked about why he doesn't use them? http://mislav.uniqpath.com/2010/05/semicolons/ http://mislav.uniqpath.com/2010/05/semicolons/ Not reading an article because of that would be like not reading other code because it uses 2 spaces for tabs instead of 4. Makes no difference to the language, only to you.
- wldlyinaccurate 13y ago
  The thing is, semicolons do make a difference with JavaScript. It's now 404ing, but there was a pretty well-known argument on one of Twitter Bootstrap's GitHub issues[1]. The Bootstrap guys didn't use semicolons, and it caused problems when minifying the code. It's an edge case, I know, but it was a problem. I never understood the whole anti-semicolon thing anyway. It just seems really hipster to me. Use CoffeeScript, if you don't want semicolons. [1] https://github.com/twitter/bootstrap/issues/3057
  - tg3 13y ago
    If it caused problems when minifying the code, the problem was with the minifier not parsing correctly - a minifier shouldn't change the way the code is interpreted. I understand that using existing minifiers is a possible reason to use semicolons, but not using semicolons is not an inherent issue here.
  - ealexhudson 13y ago
    It shouldn't, they genuinely are optional, and Javascript coders need to know when they can be inserted because you can't turn that behaviour off. However, needing to understand the rules is one thing - I much prefer to see the semi-colons in there. I dislike seeing any formatting that is substantially different from the accepted norm and find it harms readability.
  - marrs 13y ago
    Why does it seem hipster to use a language feature? Is it hipster to use null coalesce as well? The article linked above explains the reasons to omit semi-colons very well. I would personally prefer if JS forced you to terminate all statements with a semi-colon to avoid any ambiguity, but there you go. Speaking of ambiguity caused by whitespace, Coffeescript is a 1st degree offender for this. All you have to do is indent the wrong block of code, and you completely change the scope of a nested function, and you have no visual indication of your mistake whatsoever.
    - mradmin 13y ago
      It's hipster because it goes against the accepted standard way of writing Javascript. See https://news.ycombinator.com/item?id=1547647&utm_source=twitterfeed&utm_medium=twitter https://news.ycombinator.com/item?id=1547647&utm_source=twit...
      - marrs 13y ago
        My interpretation of "hipster" is being different because you think it's cool to be different. Being different because you think it's a better approach is called "making progress", either because you'll be proven right or proven wrong. I've thought about the de-facto standard way a lot and I think that it does nothing to avoid bugs while potentially misleading a coder about the language. Therefore I think it's worse. The only reason I follow the de-facto standard is because the time spent arguing about it with my peers is better spent getting work done.
        andypants 13y ago
        Nobody has any good reasons that apply to most people, both for and against semicolons. There really isn't a huge difference in either style except in rare cases. > The only reason I follow the de-facto standard is because the time spent arguing about it with my peers is better spent getting work done. Which is why that is an excellent reason. Standards are useful, so if there is one, stick to it. If there is no reason to go against the standard, then don't. > I think that it does nothing to avoid bugs while potentially misleading a coder about the language. Therefore I think it's worse. Not seeing any semicolons can also potentially mislead about the language. It is not worse, they are both misleading until you realise ASI exists. Omitting semicolons also does nothing to avoid bugs, and introduces a different (additional?) set of edge cases where bugs may appear.
  - jalfresi 13y ago
    I've always equated javascript without semi-colons with missing comments and poor commit messages. It's just inconsiderate to other developers who have to read your code. I understand that it is a "feature" of javascript (misfeature in my opinion), but the point that "everyone else does it is not a good argument" is false. We've got like 15 years of javascript written with semicolons. Stop being an inconsiderate prick and just friggin write the code like everyone else! Don't be that guy (or gal). Comment your code. Write good commit messages. Use semicolons in your javascript.
  - testing12341234 13y ago
    The link to the issue you mention is broken because the bootstrap repository moved from twitter to twbs. The new link is https://github.com/twbs/bootstrap/issues/3057 https://github.com/twbs/bootstrap/issues/3057. Also note, that ultimately regardless of personal semicolon preference, this was an issue because of a parsing bug in JSMin. It was fixed in JSMin with this commit[0]. Other minifiers such as Closure and YUI did not exhibit any issues with the code as it had been written. [0] https://github.com/douglascrockford/JSMin/commit/5ca277ea452beae1c25db3bc0ef5c81309a3daf4 https://github.com/douglascrockford/JSMin/commit/5ca277ea452...
- wrboyce 13y ago
  The article (justifying not using semicolons) seems like a rant with not real aim, beside "I am right, semicolons are wrong - and I have all these half-baked ideas to back me up". The author was actually annoying me by the time I reached "It's good coding style". One example: > My advice on JSLint: don’t use it. Why would you use it? If you believed that it helps you have less bugs in your code, here’s a newsflash; only people can detect and solve software bugs, not tools. So instead of tools, get more people to look at your code. Pretty sure lots of people use JSLint, pep8 checkers, gofmt, or whatever the equivalent tool for the language at hand is. They certainly help, one cannot deny that. Then the author goes on to pick at Crockford for suggesting people space their JS with four spaces… Yep, I'm done.
  - martin-adams 13y ago
    Giving advice to not use JSLint without a real alternative is very naive in my opinion. When I was working with a team of developers with some novice JS developers, JSLint was a godsend to pick up simple, avoidable bugs while enforcing some sanity with regards to code style.
  - andypants 13y ago
    > only people can detect and solve software bugs, not tools Stupid compilers, they've been doing it wrong this whole time.
- stefanve 13y ago
  Maybe it is not necessary but I don't see anything against it. That was the weird thing about that article all kinds of semi legit reasons why it is not necessary to use them but no reason why not to use them. I would say if there are some semi legit reasons to use them and no reason not to use them than just use them :)
- gregorkas 13y ago
  I agree with you, but still, I look at (a lot of) JavaScript every day and it's hard to explain it, but for some reason I find the lack of semicolons disturbing. I have no problem with CoffeeScript and I've also worked with Python a lot so I appreciate a language without semicolons, but I don't approve mixing the styles. I think this is more of a psychological thing than a syntax thing because if you're used to a syntax of a language, it gets embedded in your brain and with years of practice you can spot a missing semicolon from a mile away after only a quick glance over the code. People are afraid of changes and if they are used to something and that thing is taken away they become unsettled. Or their brain explodes if they see JavaScript with missing semicolons :P.
- Donito 13y ago
  Terrible article in my opinion teaching some really bad habits that will cause hard to find bugs over time. Truth is, omitting semi-colons is probably fine at smaller scale, but for larger javascript code base with multiple maintainers, it's definitely a better practice in my opinion. Oh well, no point in me saying what has already been said :)
- coldtea 13y ago
  >Did you see the article he linked about why he doesn't use them? Yes, it's bollocks, goes against standard practice, and abuses a misfeature of the JS interpreter.
- nhebb 13y ago
  I defer to Brendan Eich on the matter: https://brendaneich.com/2012/04/the-infernal-semicolon/ https://brendaneich.com/2012/04/the-infernal-semicolon/
wwweston 13y ago
I totally understand the preference for using explicit statement termination in JS. I can even understand the general preference for a non-whitespace token to terminate a statement. But I don't understand why that would cause someone's brain to explode or otherwise make it difficult for them to pick out the author's points about the language from the example code.

M4v3R 13y ago

I used the prototype mechanism several times when debugging a script that I couldn't easily change source code for. I just typed: SomeClass.prototype.someMethod Which outputs the methods source. Then you can add some debug code like console.log(xxx) or even fix a simple bug, copy the whole thing and set it again: SomeClass.prototype.someMethod = function ... Voila! Hot code push without an IDE. While that's obviously not ideal, it certainly works in some cases.

nccong 13y ago
Good point. It's a quick way to debug/experiment.
GeneralMayhem 13y ago
My favorite trick along those lines: var cache = SomeClass.prototype.someMethod; SomeClass.prototype.someMethod = function () { debugger; // or `throw "stacktrace"` cache.apply(this, arguments) } Inserts a stack trace right in the middle of executing someone else's code, which is nice for tracking down why/when that function gets called if documentation is poor, without changing functionality.

kybernetikos 13y ago

I wrote an interactive guide to javascript that covers a lot of the same material. http://caplin.github.io/new2JS/ http://caplin.github.io/new2JS/

stefanve 13y ago
Looks nice and it helpful, thanks. Maybe you could change the output so the latest output is on top instead on the bottom (more blog style). Also it would be nice to reset the output altogether

alexdf 13y ago

>>Cat.prototype = new Mammal() This is only useful if Mamaml has only methods and no properties which does not happen that often. >> Cat.prototype.constructor = Cat I never saw a practical usage of this one :-) I think these days the standard way of doing inheritance should be -> MyClass.prototype = Object.create(baseClass.prototype)

aleclarsoniv 13y ago

If the arguments you wanted to pass to a constructor were variable in length, why not just send them in an array normally instead of having to jury-rig this? Are there benefits I'm missing?

itsbits 13y ago

oh God!! why do some people have problem with adding semicolon?

warbastard 13y ago

It's breathe not breath...

GeneralMayhem 13y ago

This article does two things that are very dangerous, and never mentions the reasons why they're dangerous. * Messing with Function's prototype is very strongly frowned upon. It's tantamount to setting global variables. At the very least, give that definition an if (!Function.new) guard to prevent redefining another implementation that another script (or the browser!) has already given. * Adding methods in the constructor is awful even if you're not using inheritance, because it burns memory like crazy. If you define sayHi on Person.prototype, then every Person gets a reference to the same sayHi method. If you define this.sayHi in the constructor, then each Person you create gets its own copy of the function, making every Person heavier in memory. Not a big deal for a simple console.log, but if you have more complicated objects with a few dozen methods that you're using a bunch of you can really make things chug.

mdigi 13y ago
"In the first version, each time you create a person, a new sayHi function will be created for him, where as in the second version, only one sayHi function is ever created, and is shared amongst all persons that are created - because Person.prototype is their parent. Thus, declaring methods on the prototype is more memory efficient."
- GeneralMayhem 13y ago
  Ah, you're right, I missed that. Small amount of bile revoked. But it should have been MUCH more strongly emphasized as the only way to do it, unless you have a very good reason, not tucked down in the bottom as "oh, if you feel like it, here's a trick to make your code a little better." Especially in a tutorial that's meant for beginners in JS.
esailija 13y ago
Since this is usually downplayed because the "code is shared", to be more specific, for example in V8 in x64 (node.js, Google Chrome), the theoretical minimum memory used by a function object is 72 bytes: - Map pointer: 8 - Properties pointer: 8 - Elements pointer: 8 - Code entry pointer: 8 - Initial Map/prototype pointer: 8 - SharedFunctionInfo pointer: 8 - Context pointer: 8 - Literals/Bindings pointer: 8 - Weak fields pointer: 8 So if you have a Person class with 30 methods, the methods are taking 30 * 72 = 2160 bytes at the very least. The actual data for a person might take 200 bytes, if we store e.g. full name, age and address so in this case there is like 10x overhead. If you print the details of 200 people per page request and there are 100 people connecting to your server, you are wasting 200 * 100 * 2160 =~ 40 megabytes on memory on storing all these useless function objects at that moment. That is just crazy. And in GC language it's never just memory, a GC will eat exponentinally more CPU time when the amount of memory you use reaches closer and closer to limits.

drunken_thor 13y ago

The article could have addressed overriding methods and calling the super method. Because that isn't simple.

raju 13y ago

I wrote a similar (2 series) article a while back that attempts to explain the same thing, but with a few diagrams. I know sketching out what was going on really helped me ... http://www.looselytyped.com/blog/2012/08/18/on-prototypal-inheritance/ http://www.looselytyped.com/blog/2012/08/18/on-prototypal-in... http://www.looselytyped.com/blog/2012/08/22/on-prototypal-inheritance-part-ii/ http://www.looselytyped.com/blog/2012/08/22/on-prototypal-in...

deleted 13y ago

[deleted]

acjohnson55 13y ago

I'm bracing for the downvote, but I'm going to say this anyway: are we all taking crazy pills? I understand that we're more or less stuck with JavaScript, but this is nuts. JS has got to be one of the least intuitive, cobbled together languages I've ever had to work with. In what other language are people still having holy wars over how to separate statements? Why the heck would a constructor be a regular function if calling it without new pollutes the global namespace? JS gives us prototypes so that we can have inheritance! Great, but that doesn't actually give us a simple ability to call super. Using functions as everything is fine and good, until you have to shoehorn all the functionality you actually need into mysterious constructs like prototype, new, and apply. When the symmetries are so half-assed, at some point, it seems to me to make way more since to stop overloading the same language construct and make separate constructs for separate uses. And don't even get me started on implicit variable declaration, function hoisting, the double-equals, for...in, the necessity of self-calling functions, etc. Thank God we have libraries and alternative syntaxes now that more or less smooth over these issues and coerce the programmer into writing reasonable JS code, because green field JS is a complete quagmire. Are we seriously incapable of doing better?

wwweston 13y ago
> In what other language are people still having holy wars over how to separate statements? Probably most of the languages in popular use. It's just that the fight is usually directed towards another language. JS happens to be one of the minority where the standard allows some flexibility and debate about usage. > mysterious constructs like prototype, new, and apply They're well-defined, so they're not particularly mysterious if you take the time. > Are we seriously incapable of doing better? Really depends on how much effort you're willing to invest in learning JavaScript, instead of trying to write the code you're used to from $OTHER_OO_LANGUAGE. Everyone unwilling to do that is probably never going to be capable of doing better. This isn't to say there's anything wrong with finding another familiar set of abstractions friendly or personally productive, but personally, I find greenfield JS is pretty fun, flexible, and capable. Then again, I think the same thing about Perl (which everyone knows is one of the worst languages ever), so YMMV.
- 13y ago

wwweston 13y ago

"Someone pointed out though, that you can prevent this polluting of the namespace (those are just big words for creating global variables) by using this trick: function Person(name){ if (!(this instanceof Person)) return new Person(name) this.name = name }" This is useful for situations where you might want to be able to create anonymous objects and call a series of methods on them, which can be a nice API as any user of jQuery knows. It's also an arguably cleaner way of achieving the constructor+apply thing he does later -- no global modification of the Function prototype. A lot of the time, though, I'll just consider this my default "class" definition: function Person (args) { this.init(args); } If you want to be warned (or want others to be warned) when Person is called w/o new, this will do it (unless someone has defined init on the global namespace, so avoid that). This also makes it easier to hand around the method that does the actual construction, which is helpful for cases like constructor + apply: var p = new Person; p.init.apply(p,args); (again, without global modification of the Function prototype) or for cases where you want to refer to "superclass" methods down an inheritance hierarchy.