@Jonathan
Well, I've only used that in one particular case so far...
I wrote an ActiveRecord-inspired extensible database system in JavaScript. It has a layering mechanism where any method (whether public or private) can have preprocessors and postprocessors attached to it in order to add additional functionality in which case the attached functionality would need access to all internal data.
Specifically what I'm using it for is that the base database library is fairly slim, only containing enough logic to be functional. On top of this, I have a separate validation module that will attach itself to every appropriate method in the library that adds data validation primarily but could also be used to add something like constraint management. The validation module needs to add validation steps to internal/private methods as well as potentially look at the primary/foreign keys stored within the raw data so I needed the ability to expose it when necessary. Another example is that I have an unfinished SQL query module for it that needs to be able to access the raw data in order to return its result set.
I don't want to expose raw data such as the primary/foreign key indexes or data tables unless they're needed because if someone doesn't know what they're doing they can corrupt the entire database.
Anyways...you're right, I don't *need* to go private, its just an added measure to maintain data integrity. Data integrity alone can be enough to make it worthwhile, although its probably overkill in most cases.
↧