HasMap remove by object? (On table with few keys)

[mttc]

Where HashMap.remove(Object o)
I find only: HashMap.remove(Key) ?

I make a table with few HasMap for more key, like we discuss on:
http://groups.google.com/group/comp.../browse_thread/thread/65a8490769d257f0?hl=en#

So now I need to write the remove method that remove the object from
all HashMaps. the better way is find the Object reference by primary
key, and then remove it from all Hashmap. but I not see the hashMap
has emove(Object o) ?

 

[Tom Anderson]

Where HashMap.remove(Object o)
I find only: HashMap.remove(Key) ?

Map<K, V> map ;
V value ;
map.values().remove(value) ;

The alternative would be to store the key values along with the object, so
you have them when you need to remove it.

tom

 

[Lew]

Watch those typos. Spelling counts in Java.

Map<K, V> map ;
V value ;
map.values().remove(value) ;

mttc, this is well documented in the Javadocs for Map. Did you read
the Javadocs for Map?

 

[Roedy Green]

Map<K, V> map ;
V value ;
map.values().remove(value) ;

values() is document to return a Collection backed by the map, so
removes will remove element from the original map.

But what is values() REALLY? What sort of lookup powers does it have?
Is it actually a HashSet? or some private type.

--
Roedy Green Canadian Mind Products
http://mindprod.com
"Humanity is conducting an unintended, uncontrolled, globally pervasive experiment
whose ultimate consequences could be second only to global nuclear war."
~ Environment Canada (The Canadian equivalent of the EPA on global warming)

 

[Arne Vajhøj]

values() is document to return a Collection backed by the map, so
removes will remove element from the original map.

But what is values() REALLY? What sort of lookup powers does it have?
Is it actually a HashSet? or some private type.

No need to guess.

You can get the class name from code and you van look at the source.

A quick glance in the source says it is an anonymous class.

Arne

 

[Tom Anderson]

values() is document to return a Collection backed by the map, so
removes will remove element from the original map.

But what is values() REALLY? What sort of lookup powers does it have?
Is it actually a HashSet? or some private type.

I believe it's generally some secret inner class of the relevant Map. When
i've implemented Maps, that's how i've done it. Like:

public class SoftMap<K, V> implements Map<K, V> {
private Map<K, Reference<V>> refs ;
public Collection<V> values() {
return new Values() ;
}
private class Values extends AbstractCollection<V> {
public void clear() {
SoftMap.this.clear() ;
}
public boolean remove(V obj) {
Iterator<Reference<V>> it = refs.values().iterator() ;
while (it.hasNext()) {
Reference<V> ref = it.next() ;
V value = ref.get() ;
if (value == null) it.remove() ; // soft ref got cleared, purge
else if (value.equals(obj)) {
it.remove() ;
return true;
}
}
return false ;
}
// etc
}
}

Because it's a collection of the values, it does everything by linear
scan. Nice.

tom

 

[Lew]

I am always in hope about the Javadocs, and sometimes justifiably so.
Naturally the docs for the interface Map don't speak to implementation
details, so I turned to the docs for AbstractMap, the parent class of all the
important standard Map implementations. There they document values() to return

 

[Andreas Leitgeb]

I am always in hope about the Javadocs, and sometimes justifiably so.
Naturally the docs for the interface Map don't speak to implementation
details, so I turned to the docs for AbstractMap, the parent class of all the
important standard Map implementations. There they document values() to return

That really sounds like it boiled down to a linear search for the
value object(s).

If this is verified by tests, and if deletion by value is common in the
project at hand, then creating and maintaining a reverse-map to the original
map seems like the most efficient solution.

 

[Daniel Pitts]

That really sounds like it boiled down to a linear search for the
value object(s).

If this is verified by tests, and if deletion by value is common in the
project at hand, then creating and maintaining a reverse-map to the original
map seems like the most efficient solution.

I don't see how it could be anything but a linear search for a
delete-value, since the value's themselves are not indexed/ordered in
any way except in regards to the corresponding key.

Indeed, if you need the speed then you can use a reverse-lookup map. I
would suggest create a (generic) class that wraps both maps, in order to
prevent invariant volations.