[
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: [email protected]
For additional commands, e-mail: [email protected]
