lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Klaas" <>
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) <> wrote:
>      [
> 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?

$ find -name \*.java | xargs grep private | wc
$ find -name \*.java | xargs grep protected | wc


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message