On 4/4/07, Otis Gospodnetic (JIRA) <[EMAIL PROTECTED]> wrote:
[
https://issues.apache.org/jira/browse/LUCENE-796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Otis Gospodnetic resolved LUCENE-796.
-------------------------------------
Resolution: Fixed
Makes sense. Thanks Steve, applied. I left those 2 private attributes of MFQP
as private until somebody asks for them to be protected.
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
caused me grief in the past, and waiting for a lucene release isn't
usually a good solution--c&p is faster.
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)?
A class is either designed for extensibility in mind (or certain
kinds), or not at all. It is perhaps unrealistic to audit all lucene
classes, but perhaps a whole class could be opened up when a bug
report is filed?
FWIW:
$ find -name \*.java | xargs grep private | wc
914
$ find -name \*.java | xargs grep protected | wc
260
cheers,
-Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
