lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Klaas" <mike.kl...@gmail.com>
Subject Re: [jira] Resolved: (LUCENE-796) Change Visibility of fields[] in MultiFieldQueryParser
Date Thu, 05 Apr 2007 22:20:18 GMT
On 4/4/07, Otis Gospodnetic (JIRA) <jira@apache.org> 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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message