Hacker News Reader

Comment by Tomek_ | Hacker News Reader

Recently at my company we're writing a lot of JS and its' lack of "public/protected/private" doesn't make it easier to maintain or test. Actually, it's quite frustrating because you know you can't test it properly - everything public? it's a ticking timebomb, someone at some point will simply override your method somewhere and hell will broke loose

View on HN

Even though JS doesn't have language constructs for public/private, there are a number of different ways to write modules with hidden members by use of closures.

Crockford explains with some examples here:

http://javascript.crockford.com/private.html

I'd say that using closures and functions to create public apis with internal private structure does qualify it to have 'language constructs for public/private'.

It just took programmers collectively over 10 years to figure it out. I blame the 'new' keyword in JS, it feels completely grafted on after the fact.

Lua has been using this method of designing modular programs for years.

I know you can do it, but it produces quite an overhead and it's ugly. But that's for another discussion ("sad things in JS" maybe) - here my main point was that, no, public/protected/private is not a dumb idea in dynamic languages.

I wrote a simple library based off of Crockford's writings to make creating reusable constructor functions that supported public/protected/private simple (and without resorting to silly "if it's preceded with an underscore don't touch it!" business). It was written mainly with Node.js in mind, but you could strip out the CommonJS package stuff and use it that way.

https://github.com/zoips/Gizmo

Reply on news.ycombinator.com