lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Grant Ingersoll" <>
Subject Re: RE : Analyzers
Date Thu, 17 Jun 2004 13:30:13 GMT
Seems reasonable.  My only hesitation is the use of clone().  Not sure if this is strong enough,
as there won't be any compiler errors if someone does not override clone() (just potentially
weird behavior due to improper copying of internal Objects).  I don't know whether this is
a big deal or not.  Seems like some of the time the base clone() method will be sufficient
and other times we will need to do a deep copy.  Should we force the developer to implement
it or not?

I think the best thing may be to get it working and see what the others think.

>>> 06/17/04 06:13AM >>>
So I gave this a little thought...

AbstractTokenizer could become 
CloneableTokenizer implements Tokenizer, Cloneable 

AbstractTokenFilter could become 
CloneableTokenFilter implements TokenFilter, Cloneable

in both of which the clone() method would return a new object allowing implementations like
BaseAnalyzer to take advantage of your init() methods and setters (AbstractTokenFilter .setTokenStream
and AbstractTokenizer.setReader) OR allow each CloneableTokenizer, CloneableTokenFilter implementation
to generate its new object using its own constructor based dependency injection.

We could also remove the need for the init(), and setter methods in AbstractTokenizer and
AbstractTokenFilter and create two abstract factory methods CloneableTokenizer.clone(reader)
and CloneableTokenFilter.clone(TokenStream) which would handle TokenStream construction using
the argument and any configured class member objects (stopWords, charsets, etc).

Your thoughts...


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

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

View raw message