[
https://issues.apache.org/jira/browse/LUCENE-5388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13865620#comment-13865620
]
Robert Muir commented on LUCENE-5388:
-------------------------------------
{quote}
How about we start by adding ctors that don't require a reader, and do treat
them as 4.x fodder?
{quote}
I'd prefer not, because then there needs to be very sophisticated backwards
compat to know which one to call. and subclassing gets complicated.
I would really prefer we just choose to fix the API, either 1) 5.0-only or 2)
break it in a 4.x release
>From my perspective, Benson would be probably be the one most impacted by such
>a 4.x break. So if he really wants to do this, I have no problem.
{quote}
setReader throws IOException, but the existing constructors don't. Analyzer
'createComponents' doesn't. How to sort this out?
{quote}
I dont see the problem. I think createComponents doesnt need to throw
exception: instead the logic of Analyzer.tokenStream changes slightly, to call
components.setReader(r) in both cases of the if-then-else. Make sense?
> Eliminate construction over readers for Tokenizer
> -------------------------------------------------
>
> Key: LUCENE-5388
> URL: https://issues.apache.org/jira/browse/LUCENE-5388
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/other
> Reporter: Benson Margulies
>
> In the modern world, Tokenizers are intended to be reusable, with input
> supplied via #setReader. The constructors that take Reader are a vestige.
> Worse yet, they invite people to make mistakes in handling the reader that
> tangle them up with the state machine in Tokenizer. The sensible thing is to
> eliminate these ctors, and force setReader usage.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
