[jira] Commented: (LUCENE-2374) Add introspection API to AttributeSource/AttributeImpl
[ https://issues.apache.org/jira/browse/LUCENE-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12982334#action_12982334 ] Robert Muir commented on LUCENE-2374: - What are your thoughts here Uwe? Should we fix for 3.1 or leave till 3.2? It does seem good if we could possibly fix for 3.1 due to the fact toString() was the only real introspection we had before? But at the same time, Solr's analysis.jsp etc doesn't introspect attributes outside of the original 6 in Token anyway, so maybe we could delay? 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): - IteratorMap.EntryString,? 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2374) Add introspection API to AttributeSource/AttributeImpl
[ https://issues.apache.org/jira/browse/LUCENE-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12982335#action_12982335 ] Uwe Schindler commented on LUCENE-2374: --- Oh, I forgot about that one! Wanted to fix this. I am currently away from my computer, can we discuss tomorrow? I really wanted to fix this, sorry. 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): - IteratorMap.EntryString,? 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2374) Add introspection API to AttributeSource/AttributeImpl
[
https://issues.apache.org/jira/browse/LUCENE-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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(MapString,?)
{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):
- IteratorMap.EntryString,? 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2374) Add introspection API to AttributeSource/AttributeImpl
[
https://issues.apache.org/jira/browse/LUCENE-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12982437#action_12982437
]
Earwin Burrfoot commented on LUCENE-2374:
-
Nice. Except maybe introduce a simple interface instead of the MapString, ? ?
{code}
interface AttributeReflector { // Name is crap, should be changed
void reflect(String key, Object value);
}
void reflectWith(AttributeReflector reflector);
{code}
You have no need for fake maps then, both in toString(), and in user code.
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):
- IteratorMap.EntryString,? 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2374) Add introspection API to AttributeSource/AttributeImpl
[ https://issues.apache.org/jira/browse/LUCENE-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12982439#action_12982439 ] Uwe Schindler commented on LUCENE-2374: --- I had the same idea and I am coding it currently. 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): - IteratorMap.EntryString,? 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
