: I'm not sure if this applies to this issue, but ISTM that a "private : unless you bug the devs" approach to variable scoping is a little odd. : A few unecessary "private"s sprinkled through the code can really : wreck havoc on effects to extend functionality cleanly. This has
the trade off is that once something is "protected" it can never be removed or changed in any significant way -- making it really hard to safely make some optimizations. by saying "let's assume things are private until someone demonstrates a need to deal with it in a subclass" we can at least delay the question of extensibility/performance until it actually becomes relevent. : What if maintaining backward-compatibility of the "inheritance : interface" of classes was explicitly not guaranteed--would this allow : the default policy for new code to use protected rather than private : (unless there is a reason for the latter)? 6 vs 0.6 dozen ... if he "inheritance interface" isn't garunteed, what's the point of having something be protected? -- compilation errors are better protection against people doing something not garunteed then verbage in docs -- if people are willing to depend on something that may not be supported in teh future, they might as well make a local patchto change the visibility. : A class is either designed for extensibility in mind (or certain : kinds), or not at all. It is perhaps unrealistic to audit all lucene the key is "certain kinds" ... classes can be made extensible with the intent of changing behavior A, but with the assumption that behavior B will not be changed, and can be tweaked under the covers later -- the best way to do that is to make the data for A protected, and the data for B private. -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
