[
https://issues.apache.org/jira/browse/LUCENE-8566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16712318#comment-16712318
]
Tomoko Uchida commented on LUCENE-8566:
---------------------------------------
[~thetaphi] I have encountered a subtle question.
{quote}Don't derive the SPI names from class name anymore (we should put them
into the classes as static final constants). By that you can add compile time
safety again (user can do FooBarFactory.NAME).
{quote}
I feel like that factory classes' static final fields are somewhat
"implementation details." (Java interfaces can have static final fields, but
current factories are not based on interfaces.) Is there a major difference
between the calls of these two builder methods.
{code:java}
// by name
CustomAnalyzer.builder().withTokenizer(FooBarFactory.NAME)
// by class
CustomAnalyzer.builder().withTokenizer(FooBarFactory.class)
{code}
Could you help me to clarify what we achieve by this modification?
> Deprecate methods in CustomAnalyzer.Builder which take factory classes
> ----------------------------------------------------------------------
>
> Key: LUCENE-8566
> URL: https://issues.apache.org/jira/browse/LUCENE-8566
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/analysis
> Reporter: Tomoko Uchida
> Assignee: Uwe Schindler
> Priority: Minor
>
> CustomAnalyzer.Builder has methods which take implementation classes as
> follows.
> - withTokenizer(Class<? extends TokenizerFactory> factory, String... params)
> - withTokenizer(Class<? extends TokenizerFactory> factory,
> Map<String,String> params)
> - addTokenFilter(Class<? extends TokenFilterFactory> factory, String...
> params)
> - addTokenFilter(Class<? extends TokenFilterFactory> factory,
> Map<String,String> params)
> - addCharFilter(Class<? extends CharFilterFactory> factory, String... params)
> - addCharFilter(Class<? extends CharFilterFactory> factory,
> Map<String,String> params)
> Since the builder also has methods which take service names, it seems like
> that above methods are unnecessary and a little bit misleading. Giving
> symbolic names is preferable to implementation factory classes, but for now,
> users can write code depending on implementation classes.
> What do you think about deprecating those methods (adding {{@Deprecated}}
> annotations) and deleting them in the future releases? Those are called by
> only test cases so deleting them should have no impact on current lucene/solr
> codebase.
> If this proposal gains your consent, I will create a patch. (Let me know if I
> missed some point. I'll close it.)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
