On Thu, Apr 2, 2009 at 9:34 AM, David Jencks <david_jencks@yahoo.com> 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