On Thu, Apr 2, 2009 at 9:34 AM, David Jencks <email@example.com> wrote:
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.
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 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).
Alex, wdyt? is there any use case that requires the value, if yes, should the same semantic be applied to remove(K,V) also?