[alptrv]

I always wanted to know why would anyone want to hide their code at all? If you making a library you would never know how people going to use it. Why don't expose public interface using naming conventions and let the people freedom to break it when they really want to. I sometimes found myself using methods and variables that intended to be private because I wouldn't achieve needed functionality without touching them. Just imagine what if Backbone had all model's attributes private - that practically means that you wouldn't be able to extend a model or to inspect the model's attributes in the console. Of course you can say that adequate programmer would never do that, but that's exactly my point - you have to rely on programmer's ability to write decent code, while if everything was public you would also rely on your ability to hack things, yes this can be messy and you can shoot your leg, we all know that, but we all grown ups and we know what we are doing.

When I read about symbols in upcoming ES6 I can't get rid off the sense of anxiety because I fear thing would get worse, the only hope is that browser vendors would implement some means to inspect private state of the objects that use Symbols.

By the way, this was one of the reasons why Guido van Rossum had chosen not to add private state in Python: https://plus.google.com/115212051037621986145/posts/7wpbQTPR...

[pessimizer]

Because you'll lose the ability to refactor the internal structure of the library without breaking people's code.

[alptrv]

Well if they use your private members thats all in theirs responsibility. What if they just want to make the thing work, ship the product, whatever else, and don't care about new versions.

[skybrian]

This depends on programming culture. For example, at Google, if you commit a CL to a shared library that breaks another team, they will tell you to roll it back and fix the callers first, and you will. It's doable but it slows you down. Doesn't matter whose fault it is; they're long gone anyway.

In other situations you don't have to listen, but if a popular library doesn't pay attention to backward compatibility then they'll end up in a situation where major customers keep using an older version of their library and nobody wants to upgrade. And unless you want to keep maintaining multiple versions, you want them to upgrade.

[lmm]

If your language allows you to encapsulate state properly even within an inheritance hierarchy then that makes it a lot more possible to let users upgrade safely. Anyone who's had to upgrade a large codebase using Rails or Django knows how much trouble it can be; contrast that with upgrading Wicket which is a wonderfully smooth experience.

[ghostdiver]

think about Google Analytics tracking script