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.
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).
thanks
david jencks
thanks David
Kiran Ayyagari
