SidekickJS's blog

Enforced privacy is rude: advise instead

My previous post prompted a good debate on HN, but a few of my points got lost. So this post restates my argument that "privacy is good, some implementations are better than others".

Privacy in OO is great for communication, but causes pain if it can’t be bypassed. Advisory privacy achieves communication while letting your users do what they like with your software.

It’s rude not to let people using your code bypass privacy if they’re aware of the risks (it’s what NSA wants, right?). It’s a message that you consider them unworthy to be trusted with the internals of your code, and makes your code less fun & productive to use.

Privacy is communication*

Making something private says to your users “this is internal, and I will change it at will, do not rely on it”.

This helps your users avoid being burned when you update the library. Equally you can change the internal implementation without affecting the public API.

Advisory privacy has benefits; enforced privacy has harms

Whether an implementation of privacy is enforced or merely advisory is completely distinct from its merits for communicating danger of change.

Software which uses enforced privacy is less fun & productive because:

Considering that dynamism is one of the features most Javascripters love, why use an idiom that is so anti-dynamic?

Treat your users like adults

Open-source software wants to help people. Making it impossible to change the internals of software for your users’ “own good” is insulting: communicate the danger, let the users decide.

Application code is a different situation as you can change the source - use whatever privacy method you fancy* - but as I argued previously closure based privacy is still ugly for OO components, and makes sub-typing a chore.

Advisory privacy everywhere

Anybody who’s studied many OO languages knows that advisory privacy is common - the languages are mature and well designed, perhaps they’re on to something? Smalltalk doesn’t enforce privacy. Python’s creator explicitly prefers privacy as an “advisory mechanism, not an enforcement mechanism” via the _ convention. Ruby’s send method can call any private method.

Happy path for Javascript privacy

In Javascript, I’d suggest implementing advisory privacy via the _ prefix as it’s a well-known convention. To make it even clearer to users they’re doing a ‘naughty’ thing with your code you could prefix things with - so they have to use the longer brackets/string notation:

var MyModule = {
"-doTheThing": function() {}
}
MyModule["-doTheThing"]() // dodgy things should look dodgy

I’ve written up a complete example of advisory privacy in Javascript.

Conclusion

Advisory privacy communicates danger to your users while treating them as adults. Don’t deny them the productivity and fun of hacking about with the internals. In Javascript that means avoiding closure-based privacy for modules and classes.