Closed cjnolet closed 9 years ago
I am a little back and forth on this but I don't know if this would be good idea.
My biggest concern is that the current BaseTupleStore currently controls how tuples are stored in the internal multimap. We would need to be extra careful to make sure we add additional checks to make sure callers are using it correctly. For instance, on put, putAll, remove, removeAll, and replaceAll we would need to verify that the all the value tuples have the same key as the key passed into the method. Even if we did that in BaseTupleStore, we would need to thoroughly document the TupleStore interface so that anyone implementing the interface actually follows all the rules for how the TupleStore is expected to be handled.
A less powerful alternative may be to have a getter method that returns an unmodifiable view of the internal MultiMap to allow a caller to take advantage of guava's Multimap utilities.
This will conflict with some of the concepts in the proposed 2.0.0 changes related to making these classes immutable. For example, the add and remove methods.
Instead I propose investigating providing accessor for an unmodifiable view of the underlying multimap backing these objects.
Can this be closed?
Depends did you want to treat this as 'won't fix' or could there be some benefit to exposing the underlying multimap as an accessor?
I think for now we should close it as a wontfix. I don't have any immediate for the mutlimap as an accessor.
On Sat, Jan 24, 2015 at 12:36 AM, eawagner notifications@github.com wrote:
Depends did you want to treat this as 'won't fix' or could there be some benefit to exposing the underlying multimap as an accessor?
— Reply to this email directly or view it on GitHub https://github.com/calrissian/mango/issues/140#issuecomment-71301429.
Most of the methods on this interface are already supplied but it will allow us to use other code from Google that works on ListMultimap.