caching via XMLObject ?

[Brent Putman]

On 8/20/13 3:19 PM, Ian Young wrote:
>
> The type hierarchy for the kinds of thing that get put into item metadata in the MDA just now isn't all that complicated, so I would not expect that bug to cause problems.

Ok, good to know.

>
> The MDA does depend on ordering, though, which I guess is why the API of the class is defined in terms of List rather than Set or Collection.  For example, one internal use for the item metadata is to record the stages which have processed an item. 

Also good to know.  On a related note, I noticed that the Guava MultiMap
interface just returns a Collection from its get() and other methods, so
we'll need to think about that.  I guess a particular (like ours) could
impl can guarantee to return a specific type of collection, that has
ordering or uniqueness guarantees, etc.


>  Just replacing the List with a Set would break that.

Right, that's actually not what I was talking about.  Internally, when
put() calls the private method getSuperTypes() to get the collection of
supertype classes/interfaces to index, it accumulates those right now in
a List.  The way that the indexing loop is done right now over that,
duplicates in that type list result in duplicates in the values list.  I
think just changing that internal List to a Set would solve the
duplicate value problem trivially, although there might be a way to
refactor things to do in a different way.  But I'm *not* talking about
changing the public API of the class - get() would still return a List
and the items therein would be in original insertion order.

I'll test later this evening hopefully.  I also think I worked out the
issue with supporting remove() ops, and it should be pretty trivial to
implement also.