[
https://issues.apache.org/jira/browse/SOLR-912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12663998#action_12663998
]
Hoss Man commented on SOLR-912:
-------------------------------
Ok, Now I think I understand your type safety goal -- the existing
implementation is type safe if-and-only-if the precondition of the "List"
constructor is met (that it contains pairwise names/values) ... your goal is to
make NamedList garuntee type correctness. (correct?)
bq. If backward compatibility is the key here- I can revisit the patch again
ensuring the same.
There are a lot of internal APIs where I wouldn't be opposed to fudging
backwards compatibility in the interests of better code, but NamedList isn't
one of them. it's *the* datastructure that gets used by almost any type of
plugin people may write -- any request handler or search component that wants
to add data to the response is going to be constructing a new NamedList, so I'm
definitely not on board breaking things for all of those people.
unfortunately, i think your goal is in direct and inherent opposition to
backwards compatiblity.
As you mentioned, type erasure prevents us from adding a new
"List<Entry<String, T>>" constructor while keeping the existing "List"
constructor -- but that's not the biggest problem. We could always use tricks
(like adding an extra ignored arg to the new constructor, or making the new
constructor take in an "Entry<String, T>[]" instead of a List) to maintain
binary API compatibility, and then have the legacy constructor cast the List
elements as needed to delegate to the new constructor .... *EXCEPT* .... binary
API compatibilty is only part of backwards compatibility. The bigger problem
is this sentence in the javadocs...
{noformat}
* @param nameValuePairs underlying List which should be used to implement a
NamedList; modifying this List will affect the NamedList.
*/
public NamedList(List nameValuePairs) {
{noformat}
...it would be nice if that was just an implementation detail, and the javadocs
said "... _may_ affect the NamedList", but it says "... _will_ affect the
NamedList" Changing the internals (and that constructor) would change the
behavior our from under people who have an existing expectation that they can
maintain a refrence to the List and modify it to affect the NamedList.
Unfortunately this isn't an academic point: I've actually seen this utilized in
plugin code. People build up datastructures containing NamedLists, and then
data is added to the underlying Lists backing those NamedLists after the fact
(but before the NamedList is iterated by a response writer)
I just don't see any way to feasibly achieve your type-safe constructor goal
while maintaining back-compat.
> org.apache.solr.common.util.NamedList - Typesafe efficient variant -
> ModernNamedList introduced - implementing the same API as NamedList
> ----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-912
> URL: https://issues.apache.org/jira/browse/SOLR-912
> Project: Solr
> Issue Type: Improvement
> Components: search
> Affects Versions: 1.4
> Environment: Tomcat 6, JRE 6, Solr 1.3+ nightlies
> Reporter: Kay Kay
> Priority: Minor
> Fix For: 1.4
>
> Attachments: NLProfile.java, SOLR-912.patch, SOLR-912.patch
>
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> The implementation of NamedList - while being fast - is not necessarily
> type-safe. I have implemented an additional implementation of the same -
> ModernNamedList (a type-safe variation providing the same interface as
> NamedList) - while preserving the semantics in terms of ordering of elements
> and allowing null elements for key and values (keys are always Strings ,
> while values correspond to generics ).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
