On Apr 1, 2009, at 10:28 PM, Kiran Ayyagari wrote:

David Jencks wrote:
Why isn't it V insert(K, V)? =A0AvlTreeMap 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 dupli= cates
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 =3D = 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. =A0I figured that "put"= methods only return a value when they replace a previous value. =A0If dupl= icates are allowed, then put will never replace a value and always return n= ull. =A0If duplicates are not allowed, then there will be 0 (null) or 1 (V)= objects to return.

+1
=A0

Alex, wdyt? is there any use case that requires the value, if yes, should t= he 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. =A0In that case r= eturning AvlTree<V> might be more appropriate. =A0On the other hand m= y naive expectations would be that remove(K, null) would only remove someth= ing is insert(K, null) had been called. =A0If I wanted to remove all the va= lues associated with a K I'd want a method remove(K) and having this re= turn an AvlTree(V) seems more appropriate (this could be a singleton if the= re is only one value).

+1

These were my thoughts exactly.=A0 I think= the problem was we copied the AvlTree<V> as a starting point for Avl= TreeMap<K,V>.=A0

Thanks for the clarification David.

Alex
--00221532cf34ebd3d904668d9ec1--