4 ms·
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 fr
by Tomek_ 15y ago
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
- mryall 15y agoEven 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 http://javascript.crockford.com/private.html
- ryan-allen 15y agoI'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_ 15y agoI 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.
- zoips 15y agoI 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 https://github.com/zoips/Gizmo