Javascript Constructors and Prototypes

This article does two things that are very dangerous, and never mentions the reasons why they&#x27;re dangerous.<p>* Messing with Function&#x27;s prototype is very strongly frowned upon. It&#x27;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.<p>* Adding methods in the constructor is awful even if you&#x27;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 <i>same</i> sayHi method. If you define this.sayHi in the constructor, then each Person you create gets <i>its own copy</i> 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&#x27;re using a bunch of you can really make things chug.

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

I used the prototype mechanism several times when debugging a script that I couldn&#x27;t easily change source code for. I just typed:<p>SomeClass.prototype.someMethod<p>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:<p>SomeClass.prototype.someMethod = function ...<p>Voila! Hot code push without an IDE. While that&#x27;s obviously not ideal, it certainly works in some cases.

I&#x27;m bracing for the downvote, but I&#x27;m going to say this anyway: are we all taking crazy pills?<p>I understand that we&#x27;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&#x27;ve ever had to work with. In what other language are people still having holy wars over how to separate statements?<p>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&#x27;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.<p>And don&#x27;t even get me started on implicit variable declaration, function hoisting, the double-equals, for...in, the necessity of self-calling functions, etc.<p>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?

&quot;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:<p><pre><code> function Person(name){ if (!(this instanceof Person)) return new Person(name) this.name = name }&quot; </code></pre> 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.<p>It&#x27;s also an arguably cleaner way of achieving the constructor+apply thing he does later -- no global modification of the Function prototype.<p>A lot of the time, though, I&#x27;ll just consider this my default &quot;class&quot; definition:<p><pre><code> function Person (args) { this.init(args); } </code></pre> If you want to be warned (or want others to be warned) when Person is called w&#x2F;o new, this will do it (unless someone has defined init on the global namespace, so avoid that).<p>This also makes it easier to hand around the method that does the actual construction, which is helpful for cases like constructor + apply:<p><pre><code> var p = new Person; p.init.apply(p,args); </code></pre> (again, without global modification of the Function prototype) or for cases where you want to refer to &quot;superclass&quot; methods down an inheritance hierarchy.

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

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 ...<p><a href="http://www.looselytyped.com/blog/2012/08/18/on-prototypal-inheritance/" rel="nofollow">http:&#x2F;&#x2F;www.looselytyped.com&#x2F;blog&#x2F;2012&#x2F;08&#x2F;18&#x2F;on-prototypal-in...</a><p><a href="http://www.looselytyped.com/blog/2012/08/22/on-prototypal-inheritance-part-ii/" rel="nofollow">http:&#x2F;&#x2F;www.looselytyped.com&#x2F;blog&#x2F;2012&#x2F;08&#x2F;22&#x2F;on-prototypal-in...</a>

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

I wrote an interactive guide to javascript that covers a lot of the same material.<p><a href="http://caplin.github.io/new2JS/" rel="nofollow">http:&#x2F;&#x2F;caplin.github.io&#x2F;new2JS&#x2F;</a>

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&#x27;m missing?

The article could have addressed overriding methods and calling the super method. Because that isn&#x27;t simple.

It&#x27;s breathe not breath...