undefined | Better HN

0 pointsTomek_15y ago0 comments

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

0 comments

4 comments · 2 top-level

mryall15y ago· 2 in thread

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

ryan-allen15y ago

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.

Tomek_OP15y ago

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.

zoips15y ago

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

j / k navigate · click thread line to collapse