[
https://issues.apache.org/jira/browse/LUCENE-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982429#action_12982429
]
Uwe Schindler commented on LUCENE-2374:
---------------------------------------
I will work tomorrow on a patch with sophisticated backwards for 3.x and merge
to trunk without sophisticated things *g*.
I changed my mind a little bit: I would simplify the whole thing:
AttributeSource and AttributeImpl should have a simple method:
{code}
void addToMap(Map<String,?>)
{code}
The default code would simply look like AttributeImpl.toString() now and add
all non-static fields to the impl - special attributes like CharTermAttribute
would have special handling. The default toString() [if not overridden] would
simply call this method, too and pass a Fake-Map to the addToMap() method to
populate a StringBuilder in Map.put() [to not automatically create a real Map
always).
Code in analysis.jsp would simply pass a map (e.g. a LinkedHashMap to preserve
order) and then print it out. The values in the map are native types / or
CharSequence for (Char)TermAttribute.
The only problem with this aproach would be that the attribute keys must be
unique - an idea would be to prefix them with the attribute name.
I will also remove the abstract equals() and hashCode() in AttributeImpl - the
attribute API does not rely on them to be implemented - this simplyfies
implementation of attributes, because equals/hashCode are never used. In 4.0 I
would remove this from all custom attributes.
What do you think?
> Add introspection API to AttributeSource/AttributeImpl
> ------------------------------------------------------
>
> Key: LUCENE-2374
> URL: https://issues.apache.org/jira/browse/LUCENE-2374
> Project: Lucene - Java
> Issue Type: Improvement
> Components: contrib/analyzers
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Fix For: 3.1, 4.0
>
>
> AttributeSource/TokenStream inspection in Solr needs to have some insight
> into the contents of AttributeImpls. As LUCENE-2302 has some problems with
> toString() [which is not structured and conflicts with CharSequence's
> definition for CharTermAttribute], I propose an simple API that get a default
> implementation in AttributeImpl (just like toString() current):
> - Iterator<Map.Entry<String,?>> AttributeImpl.contentsIterator() returns an
> iterator (for most attributes its a singleton) of a key-value pair, e.g.
> "term"->"foobar","startOffset"->Integer.valueOf(0),...
> - AttributeSource gets the same method, it just concat the iterators of each
> getAttributeImplsIterator() AttributeImpl
> No backwards problems occur, as the default toString() method will work like
> before (it just gets iterator and lists), but we simply remove the
> documentation for the format. (Char)TermAttribute gets a special impl fo
> toString() according to CharSequence and a corresponding iterator.
> I also want to remove the abstract hashCode() and equals() methods from
> AttributeImpl, as they are not needed and just create work for the
> implementor.
--
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]
