[
https://issues.apache.org/jira/browse/SOLR-12959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16675653#comment-16675653
]
David Smiley commented on SOLR-12959:
-------------------------------------
I mistook the class level javadocs to be obsolete, and I've not understood it
well (embarrassing perhaps). Even if it's docs are correct, I still find the
class odd. One thing -- I thought "json.nl" is what toggles these two
representations:
{noformat}
{"foo":10,"bar":20}
vs
["foo",10,"bar",20]
{noformat}
Yet the docs seem to suggest it's SimpleOrderedMap vs (plain) NamedList that
will as well? IMO: Yuck. that latter format is unfortunate as it doesn't
semantically represent the structure; it should merely be an _option_ that the
user can toggle with json.nl if they so choose. Perhaps we should shy away
from even having repeated keys in the first place, favoring array values
instead.
Second is the name... as a subclass of NamedList I think it could certainly be
better. "Simple"ness isn't interesting (is there a complex variant?).
OrderedMap... maybe not a great name given "Map" has loaded assumptions in the
JDK (i.e. no repeated key). If we need a subclass of NamedList then it
probably ought to have "NamedList" as part of its name.
I think we can _do something_ to improve things here. Feel free to recommend
something Hoss or AB.
> Deprecate solrj SimpleOrderedMap
> --------------------------------
>
> Key: SOLR-12959
> URL: https://issues.apache.org/jira/browse/SOLR-12959
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
> Reporter: Noble Paul
> Priority: Minor
>
> There is no difference between a NamedList and a SumpleOrderedMap. It
> doesn't help to have both of them when they are doing exactly free same things
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
