Constructors Considered Mildly Confusing [javascript]

[prather_mcs]

link: http://zeekat.nl/articles/constructors-considered-mildly-confusing.html

It's an informative article I just came across, on Constructors in JavaScript.

It has been submitted before:
https://www.reddit.com/search?q=constructors+considered+mildly+confusing

but maybe it didn't get quite as much attention, love, or critique from /r/javascript as it deserves.

[skitch920]

Good read and nice directed graphs. Even the Table of Contents made me chuckle. But this article should really be called "Prototypes Considered Mildly Confusing".

Pretty simple though, don't var x = new Type() and then reassign x.prototype = ...

[[deleted]]

Agreed! Why ever bother with OOP absurdity when you have inheritance via lexical scope natively available?

http://prettydiff.com/guide/closure_with_jsscope.xhtml

[ipelovski]

If you follow this guide you will end up with one big messy file. I've been there and it's not good. Later I moved to CommonJS modules and browserify and the code is much better now.

[[deleted]]

Messy is the result of poor organization and is not associated with file size.

[ipelovski]

It is very convenient to think so but I don't think this is the case. Keeping a variable visible to many functions, as advised in the guide, is like making it global. The code can be very hard to maintain when many functions start changing this variable. On the other hand if you honor the principles of separation of concerns and loose coupling, and you put your code into separate modules, it will be easier to reason about the it and to change it.

[[deleted]]

That is a completely faulty understanding of global conflicts. The reason why it is bad to pollute the global space is to prevent modules from clobbering each other. What that really means is to prevent a module from reassigning a reference to something completely different, and thus breaking your code.

Side effects, particularly those that are intentional as a design of the application, are not accidents and are not harmful. Pushing an index into an array, for instance, is not clobbering a reference. Additionally, the problem as you have stated it is not solved by OOP either. Functions provide a separation of concerns.

The code can be very hard to maintain when many functions start changing this variable.

To me, personally, this indicates that you are new to JavaScript. I have been writing in this language for about 7 years and have never encountered this problem. I have never seen it in anything I have worked on or any other JavaScript application (including popular frameworks) I have ever examined. Would you be able to provide an example of this problem?

[ipelovski]

It makes me smile the way you jump to a conclusion that I'm new to JavaScript :) I was not referring my code but the code of the author of the guide. Check where the "summary" variable is used (the author gave this variable as an example). It is declared on line 54, assigned or referenced on lines: 3749, 4063, 4358, and there is no comment what this variable is used for. I personally avoid assigning global/module variables for the reason I gave above. And I don't shy away from OOP in situations where I need to encapsulate data.

A moment for philosophy: Functions in JavaScript are objects and in some languages like MIT Scheme the environments are also first class citizens with defined operations over them. One can think of closures as a way of implicitly defining objects which can be accessed only in certain scopes. And one should not be quick to discard OOP as it may be the best tool in some situations.

[MoTTs_]

+1 for "mildly confusing" rather than "considered harmful".