Following Guava on this has something to be said for it.
https://code.google.com/p/guava-libraries/wiki/NewCollectionTypesExplained
Their decision is that Multimap#get returns a collection always. If there
are no values, then an empty collection is returned so that you can always
do
m.get(key).size()
or
m.get(key).add(foo)
The value returned is a magical view which only takes up space on demand so
there is little consing done. There is an asMap method for which get will
return null on missing keys.
On Thu, Mar 27, 2014 at 2:55 PM, Paul Benedict <pbened...@apache.org> wrote:
> 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
>
