[
https://issues.apache.org/jira/browse/LUCENE-2979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13011539#comment-13011539
]
Phillipe Ramalho commented on LUCENE-2979:
------------------------------------------
Here are my initial thoughts:
There will be two types of config classes, as there is today, one for global
configuration and other for field configuration. The global config class will
hold reference to the field configurations. The field configuration will have
the field name. They both will extend a common class, which is some kind of map.
The key will be an special type (ConfigKey). This ConfigKey class will be final
and will receive a generic argument when constructed. The user will need to
define it and always use the same constants. To make sure the user uses it
correctly, we can enforce ConfigKey.equals to only return true when the same
instance is passed to equals method, so the map will only return the object for
that key when the defined key is used. Example:
{quote}
// developer code
final public static ConfigKey<String> MY_CONFIG_KEY = new ConfigKey<String>();
...
String myConfig = getConfig().get(MY_CONFIG_KEY);
/////////////////
// user code
getConfig().set(MY_CONFIG_KEY, "value1"); // works
getConfig().set(new ConfigKey<String>(), "value1"); // does not work, as the
developer's code will look up for the key the developer has previously defined,
any other instance passed as key won't be found when the developer's code is
executed
{quote}
I couldn't find a way to do the generic capability above with Enum. Actually, I
don't see any reason to use Enum in this case.
Thoughts?
> Simplify configuration API of contrib Query Parser
> --------------------------------------------------
>
> Key: LUCENE-2979
> URL: https://issues.apache.org/jira/browse/LUCENE-2979
> Project: Lucene - Java
> Issue Type: Improvement
> Components: contrib/*
> Affects Versions: 2.9, 3.0
> Reporter: Adriano Crestani
> Assignee: Adriano Crestani
> Labels: api-change, gsoc, gsoc2011, lucene-gsoc-11, mentor
> Fix For: 3.2, 4.0
>
>
> The current configuration API is very complicated and inherit the concept
> used by Attribute API to store token information in token streams. However,
> the requirements for both (QP config and token stream) are not the same, so
> they shouldn't be using the same thing.
> I propose to simplify QP config and make it less scary for people intending
> to use contrib QP. The task is not difficult, it will just require a lot of
> code change and figure out the best way to do it. That's why it's a good
> candidate for a GSoC project.
> I would like to hear good proposals about how to make the API more friendly
> and less scaring :)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
