An introduction to the JavaScript Module Pattern | Hacker News Reader

An introduction to the JavaScript Module Pattern

javascriptplayground.com

36 pointsjackfranklin15 comments

It's worth noting that if you're planning on instantiating multiple instances of the same "class" (to use the term generically/loosely) instead of immediately invoking the function, the module pattern has a much more significant memory footprint than prototypical inheritance — total memory usage should increase linearly with the number of objects you're creating, since you're creating new copies of all member functions each time.

Jeremy Ashkenas (who knows a lot more about this than I do) explains this in another comment thread here: http://news.ycombinator.com/item?id=2991904

I've always felt that going out of your way to enforce information hiding in programming was kind of silly. Establish in your documentation what is public and what is private and then don't worry about it. If someone wants to hack on your private variables, you aren't going to stop them with this or any other pattern, and if they want their code to work properly, a comment that says "private" will tell them what not to mess with.

Agreed, completely.

And if you want to go further, a convention that anything starting with an underscore is private, and probably shouldn't be accessed or called without good reason and the understanding that it may break or change at any time is a good idea. (This is how Python works.)

In the real world, enforcing information hiding isn't really useful.

What if you want a clean API? What if you want the users of your code to be able to instantiate an instance and inspect that object in the console, seeing only the public methods and not having them get lost in a sea of private stuff?

Hmmmm. The Python convention of semi-private methods starting with an underscore would do the trick.

I've been burnt in the past with using someone else's javascript code and finding out that something I needed to modify they hadn't deemed public for some weird reason.

Forking the code isn't the best pattern for code reuse.

FWIW, If you want instantiate-able objects, the module pattern is probably the wrong option in that case anyway.

Or if ECMAscript 5 is an option checkout

object.defineProperty

allows specification of getter, setter, and writable flag (among others).

The syntax is ugly. They should've made it a little less verbose.

I'm sure CoffeeScript will adopt a much more elegant syntax for the feature :)

That might be a quite distant future. See:

"Unsupported features" at https://github.com/jashkenas/coffee-script/wiki/FAQ

https://github.com/jashkenas/coffee-script/issues/451

https://github.com/jashkenas/coffee-script/issues/64

https://github.com/jashkenas/coffee-script/issues/322

Nice site. I really appreciate that people are promoting better JavaScript practices these days. There can't be enough articles about that in my opinion -- there's still plenty of terrible JavaScript code out there. Keep up the good work.

I find it's enough to suffix (or prefix) a method or property with an underscore.

If calling code uses it knowingly, then they should know it's bound to break in future. The overhead (cognitive, and possibly execution) of not exposing the property isn't worth it, I think.

See the previous discussion: http://news.ycombinator.com/item?id=3813598

Does anyone else think it would be a good idea to also name the internal methods/functions with an underscore?

There's no advantage or disadvantage to underscores. It somewhat makes sense on an exposed object to denote to the consumer that they shouldn't call/use the property. otherwise it doesn't matter.

Reply on news.ycombinator.com