[ 
https://issues.apache.org/jira/browse/LUCENE-2191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12799167#action_12799167
 ] 

Uwe Schindler commented on LUCENE-2191:
---------------------------------------

The transition to the new name still has problem even with VirtualMethod from 
LUCENE-2188:
If we delegate from the new method to the deprecated one when a subclass 
overrides the deprecated one, we produce a endless loop:
- Consumer class setReader()
- setReader() detects that reset() was overridden and delegates to reset()
- reset() calls super.reset();
- the default impl of reset() in the base class delegates to setReader() for 
backwards compatibility (and it must do this).

This problem can only be solved by a thread local boolean that prevents 
delegation if setReader() was called twice in the same thread. At the moment, I 
have no other solution without inspecting the call stack...

> rename Tokenizer.reset(Reader) to Tokenizer.setReader(Reader)
> -------------------------------------------------------------
>
>                 Key: LUCENE-2191
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2191
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Analysis
>            Reporter: Robert Muir
>            Priority: Minor
>
> in TokenStream there is a reset() method, but the method in Tokenizer used to 
> set a new Reader is called reset(Reader).
> in my opinion this name overloading creates a lot of confusion, and we see 
> things like reset(Reader) calling reset() even in StandardTokenizer...
> So I think this would be some work to fulfill all the backwards 
> compatibility, but worth it because when you look at the existing 
> reset(Reader) and reset() code in various tokenizers, or the javadocs for 
> Tokenizer, its pretty confusing and inconsistent.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

Reply via email to