The downside of it returning an empty collection is you either have (1) to instantiate a collection just to say you have nothing or (2) you use an immutable collection. #1 is bad in itself and #2 is only as bad if the collection is otherwise writable. For example, it would be really strange for the returned collection to be mutable if you have something but immutable if you have nothing.
My preference is you return null. That's the most rational answer, imo. On Thu, Mar 27, 2014 at 4:44 PM, Thomas Neidhart <thomas.neidh...@gmail.com>wrote: > Hi, > > we are currently working on a new MultiValuedMap interface for > collections, see https://issues.apache.org/jira/browse/COLLECTIONS-508. > > During the work we stumbled across an issue we would like to discuss. > The MultiValuedMap is basically a Map that can hold multiple values > associated to a given key. Thus the get(K key) method will normally > return a Collection. > > In case no mapping for the key is stored in the map, it may either > return null (like a normal map), or an empty collection. > > I would be in favor to define that get() always returns a collection and > never returns null. The advantage being that the result of get() can > safely be used for further operations, e.g. size(), iterator(), ... > keeping the interface of MultiValuedMap smaller and simple (i.e. no need > to add additional methods there like size(K key) or iterator(K key)). > > The containsKey method would have to check if there is either no mapping > at all for the key or the stored collection is empty: > > public boolean containsKey(K key) { > Collection coll = decoratedMap().get(key); > return coll != null && coll.size > 0; > } > > The downside would be that read operations may also alter the map thus > leading to unexpected ConcurrentModificationExceptions when iterating on > e.g. value(). > > So, I would be interested on opinions about this. > > Thomas > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Cheers, Paul
