Mailing-List: contact lucene-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Lucene Developers List" <lucene-dev@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <421E6ED3.9040402@newsmonster.org>
Date: Thu, 24 Feb 2005 16:18:27 -0800
From: "Kevin A. Burton" <burton@newsmonster.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616
MIME-Version: 1.0
To: Lucene Developers List <lucene-dev@jakarta.apache.org>
Subject: Re: Patch - IndexReader methods and MultiSearcher methods...
References: <421E393A.40801@newsmonster.org> <421E4001.4000309@apache.org>
 <421E451E.9030704@newsmonster.org> <421E5F20.8080906@apache.org>
In-Reply-To: <421E5F20.8080906@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Doug Cutting wrote:

>
> Then use SearcherCache.getSearcher() whenever you need a searcher.  
> You could make it more complicated, e.g., have it automatically update 
> the searcher when the index has changed, etc.  But none of that 
> requires or is in particular faciliated by subclassing IndexSearcher, 
> so far as I can see.
>
This is just 1 issue with a patch that had 3 features.  I'd assume the 
other patches can go through. :)

I *realize* that there are other ways to do this but we have some legacy 
code that can't be rewritten right now.   Thus the change to protected 
and using a reloadable implementation.

>> Why don't we do this.  I don't think we should have a setReader 
>> then.  This way there's no strong contract that developers preserve 
>> things that might break caching.  I'd like to keep the protected 
>> change though.  
>
>
> Making the field protected is just an obscure way of making it 
> changeable.  If we really need to make it settable, then we should add 
> a setReader() method and add some cautions to its documentation.  But 
> I'm not yet convinced this needs to be settable.
>
This is just a pet peeve of mine.  There's no reason to prevent 
innovation here and make it hard.  If I know what I'm doing I'm going to 
recompile from source and changed it to protected ;).  Doing so however 
takes time and its a pain to change everytime I have to upgrade.  Having 
this class protected allows for expert developers who know what they're 
doing to take their own risks and provide innovative solutions.

This is slighly off topic but the entire ECB project (ecb.sf.net) 
wouldn't exist if it weren't for some smart Emacs developers adding 
function advice.

Anyway... adding protected doesn't seem like the end of the world. If 
you don't want to add it thats fine but there are two other patches 
there which aren't very controversial so I'd like to get those accepted :)

Kevin

-- 

Use Rojo (RSS/Atom aggregator).  Visit http://rojo.com. Ask me for an 
invite!  Also see irc.freenode.net #rojo if you want to chat.

Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html

If you're interested in RSS, Weblogs, Social Networking, etc... then you 
should work for Rojo!  If you recommend someone and we hire them you'll 
get a free iPod!
    
Kevin A. Burton, Location - San Francisco, CA
       AIM/YIM - sfburtonator,  Web - http://peerfear.org/
GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412


---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org