convergejd

I don't disagree with anything you said, which makes me think I worded my response incorrectly. I was using the author's term "true privacy", but what I meant is traditional privacy that, when not explicitly attempting to circumvent it, will generate some negative action, such as a warning or a compilation error. My problem was the author's blanket assertion that this type of privacy is bad and should be avoided, even if it is available.

If you need extension, you wouldn't use this pattern.

If you need to avoid this technique entirely because you're so frequently needing to unit test private methods, you have a design problem, not a testing problem.

Readability is subjective. Personally I tend to find this style a bit more readable than trying to use a naming convention to indicate privacy, as suggested later in the article.

Tooling -- any real world examples of this? It seems to me tooling would only need to worry about the public interface, not the private details.

"True privacy is a bad idea in OO" - You didn't limit this statement to javascript, so I just want to say this is ludicrous. Access control is an extremely valuable tool when you're building a large system where development may be spread amongst many teams. If you just meant client side JS, I would say your statement is debatable.

When you utilize true privacy, you're taking a very disciplined approach to building software. You prevent monkey patching or tinkering with the internal state from components who should not be concerned with that object's internal state. When you need changes, it forces you to think about how your changes impact the overall structure of your application, and whether you need to restructure aspects of your application in response to those changes. Without true privacy, sure, you could just patch some "private" method and move on with your life. As you utilize this technique more and more, however, and your application grows, it has the potential to turn into a big headache.