Issue 72 in google-collections: Review our collections which accept backing collections from the user

0 views
Skip to first unread message

codesite...@google.com

unread,
Jul 22, 2008, 3:38:37 PM7/22/08
to google-coll...@googlegroups.com
Issue 72: Review our collections which accept backing collections from
the user
http://code.google.com/p/google-collections/issues/detail?id=72

Comment #1 by jared.l.levy:
Here's a list of such collections in the library.

ConcurrentMultiset(ConcurrentMap<E,Integer>) constructor

Multimaps.newMultimap(), newListMultimap(), newSetMultimap(), newSortedSetMultimap()

ReferenceMap(ReferenceType keyReferenceType, ReferenceType valueReferenceType,
ConcurrentMap<Object,Object> backingMap) constructor


I left out cases like Comparators.givenOrder(), Multisets.unmodifiableMultiset(),
Multimaps.forMap(), Sets.union(), and the Forwarding* classes, for
which this issue's
concerns don't apply. We care about the situations when the code
sometimes uses a
user-provided backing collection and sometimes doesn't.

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings

codesite...@google.com

unread,
Jul 22, 2008, 3:42:39 PM7/22/08
to google-coll...@googlegroups.com
Issue 72: Review our collections which accept backing collections from
the user
http://code.google.com/p/google-collections/issues/detail?id=72

Comment #2 by kevinb9n:
Great, thanks. Bob is determined that we remove that RefMap
constructor. I also
think we can lose the ConcurrentMultiset one. I'll leave it to you to
decide what to
do for the Multimaps ones.

codesite...@google.com

unread,
Jul 22, 2008, 4:28:02 PM7/22/08
to google-coll...@googlegroups.com
Issue 72: Review our collections which accept backing collections from
the user
http://code.google.com/p/google-collections/issues/detail?id=72

Comment #3 by jared.l.levy:
I'd rather keep the new*Multimap methods. since the benefits of
creating a multimap
with arbitrary backing collections are more compelling.

However, I'm fine with getting rid of the other two. The most probable
reasons for
wanting an explicit ConcurrentMap are
1) specifying the ConcurrentHashMap initialCapacity/loadFactor/concurrencyLevel
2) specifying a ConcurrentSkipListMap for a deterministic sort order

If those features are requested, we could create factory methods that
take those
parameters explicitly. Besides, a ConcurrentSkipListMap by itself
wouldn't be enough
for a sorted ReferenceMap with weak or soft references, since the ReferenceMap
implementation doesn't store the keys directly in the map.

Reply all
Reply to author
Forward
0 new messages