Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: pass (herse.apache.org: domain of mike.klaas@gmail.com
 designates 64.233.184.225 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=ffVGXroj4k2SDkweOltHR2gGNopluZzcgRGEpvLkyWGvBf3VVPZJdHkDHJxW4aBladAv1ZkwAO36QFaTSoO0DOJWryeDM+8MR3WfLvlPYH27trM28px5AkufQYd4Xtmnvc0mrCGfz0Fyf4iG/4V13z+k4Yty7YzbnFH/iOq1kKo=
Message-ID: <3d2ce8cb0704051520m5f133eb3pfa3b55c46151602f@mail.gmail.com>
Date: Thu, 5 Apr 2007 15:20:18 -0700
From: "Mike Klaas" <mike.klaas@gmail.com>
To: java-dev@lucene.apache.org
Subject: Re: [jira] Resolved: (LUCENE-796) Change Visibility of fields[] in
 MultiFieldQueryParser
In-Reply-To: <24781513.1175738912562.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <11531223.1170759965935.JavaMail.jira@brutus>
	 <24781513.1175738912562.JavaMail.jira@brutus>

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