On Thu, Apr 2, 2009 at 9:34 AM, David Jencks <[email protected]> wrote:
> > On Apr 1, 2009, at 10:28 PM, Kiran Ayyagari wrote: > > >> >> David Jencks wrote: >> >>> Why isn't it V insert(K, V)? AvlTreeMap doesn't appear to extend >>> anything.... I don't see how returning the supplied key is very useful >>> whereas returning the previous value if any is quite useful. >>> >> >> that makes sense, cause its a map, but one issue is this map supports >> duplicates >> also, in this case the 'value' defined as V will not be of the same type >> as the one given during instantiation. >> e.x given the declaration as AvlTreeMap<Integer,Integer> treeMap = new >> AvlTreeMap<Integer,Integer>() >> in case duplicates are enabled the 'value' will hold a AvlTree type. >> >> This can easily lead to CCE without some extra checks. >> > > I don't quite see your point of view. I figured that "put" methods only > return a value when they replace a previous value. If duplicates are > allowed, then put will never replace a value and always return null. If > duplicates are not allowed, then there will be 0 (null) or 1 (V) objects to > return. > +1 > > > >> >> Alex, wdyt? is there any use case that requires the value, if yes, should >> the same semantic be applied to remove(K,V) also? >> > > I don't see how a return from this can be useful unless something like > remove(K, null) removes all the values associated with K. In that case > returning AvlTree<V> might be more appropriate. On the other hand my naive > expectations would be that remove(K, null) would only remove something is > insert(K, null) had been called. If I wanted to remove all the values > associated with a K I'd want a method remove(K) and having this return an > AvlTree(V) seems more appropriate (this could be a singleton if there is > only one value). > +1 These were my thoughts exactly. I think the problem was we copied the AvlTree<V> as a starting point for AvlTreeMap<K,V>. Thanks for the clarification David. Alex
