[
https://issues.apache.org/jira/browse/LUCENE-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13028189#comment-13028189
]
Robert Muir commented on LUCENE-3055:
-------------------------------------
{quote}
Also, if reusableTokenStream is the only method left standing, isn't it wise to
hide actual reuse somewhere in Lucene internals and turn Analyzer into plain
and dumb factory interface?
{quote}
Hi Earwin: I completely agree that somehow Analyzer should be a "plain and
dumb" interface, but are you suggesting we should move the responsibility of
reuse onto the consumer? I think this could be challenging, alternatively there
might be a way to present a "plain and dumb" API with the reuse guts buried
inside Analyzer itself (like ReusableAnalyzerBase), and reuse enforced (e.g.
the tokenStream() is final and you cannot "disable" reuse). The trick would be
handling the special cases such as AnalyzerWrappers but I feel like we could
still do this.
Either way, I really think we should try to do this for 4.0. Though I think to
get there it would be safest if we addressed a few issues first:
* LUCENE-2788: make charfilters reusable, otherwise we will make the same
mistake again!
* LUCENE-3064: ensure consumers are properly using the API e.g. calling reset()
* LUCENE-3040: cut all consumers over to reusable API, so its really the "one
left standing"
> LUCENE-2372, LUCENE-2389 made it impossible to subclass core analyzers
> ----------------------------------------------------------------------
>
> Key: LUCENE-3055
> URL: https://issues.apache.org/jira/browse/LUCENE-3055
> Project: Lucene - Java
> Issue Type: Bug
> Components: Analysis
> Affects Versions: 3.1
> Reporter: Ian Soboroff
>
> LUCENE-2372 and LUCENE-2389 marked all analyzers as final. This makes
> ReusableAnalyzerBase useless, and makes it impossible to subclass e.g.
> StandardAnalyzer to make a small modification e.g. to tokenStream(). These
> issues don't indicate a new method of doing this. The issues don't give a
> reason except for design considerations, which seems a poor reason to make a
> backward-incompatible change
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
