lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Collins <chris_j_coll...@yahoo.com>
Subject Re: Analyzer as an Interface?
Date Tue, 19 Jul 2005 20:29:37 GMT
I think there is a cost involved with this too isnt there?  I believe there is
an extra type check that has to be performed at runtime with interfaces that
would make it a tad slower.  Since these types of entities are sitting in tight
loops it may have a negative effect on performance.

--- Wolfgang Hoschek <whoschek@lbl.gov> wrote:

> On Jul 19, 2005, at 12:58 PM, Daniel Naber wrote:
> 
> > Hi,
> >
> > currently Analyzer is an abstract class. Shouldn't we make it an  
> > Interface?
> > Currently that's not possible, but it will be as soon as the  
> > deprecated
> > method is removed (i.e. after Lucene 1.9).
> >
> > Regards
> >  Daniel
> >
> 
> Daniel, what's the use case that would make this a significant  
> improvement over extending and overriding the single abstract method?  
> Classes that implement multiple interfaces? For consistency, similar  
> thoughts would apply to TokenStream, IndexReader/Writer, etc. Also  
> note that once it's become an interface the API is effectively frozen  
> forever. With abstract classes the option remains open to later add  
> methods with a default impl. (e.g. tokenStream(String fieldName,  
> String text) or whatever).
> 
> Thanks,
> Wolfgang.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
> 
> 




---------------------------------------------------------------------
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