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. >>> [EMAIL PROTECTED] 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... Regards, RBP --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
