> Someone could have fixed it locally. It's only a 2 character change.
good point.
> > Another option that might be useful is to add a protected
> method, taking
> > both the key and value as arguments, that's called when an
> element is
> > removed. Rather than having subclasses override the
> "removeLRU" method,
> > they would override this method and process it appropriately.
> >
> > For example:
> >
> > protected void processRemovedLRU(Object key, Object value) {
> > }
> >
> > This might actually be safer for subclasses since they
> don't actually need
> > to do the remove.
>
> That's a possibility. You would still need to provide a
> replacement for the
> public method, unless it's no longer necessary. Personally I
> didn't see a
> need for it except in subclassing, once I patched the class to use
> removeLRU() internally.
public Map.Entry getLeastRecentlyUsed() {
...
}
public Object getLeastRecentlyUsedKey() {
...
}
That should be enough to allow a "public" replacement:
map.remove(map.getLeastRecentlyUsedKey());
or
Map.Entry lru = map.getLeastRecentlyUsed();
map.remove(lru.getKey());
If you want to maintain that particular API:
public Object removeLRU() {
// use this, or a smarter implementation that uses the internals.
Map.Entry lru = this.getLeastRecentlyUsed();
this.remove(lru.getKey());
// return the key as per current impl
return lru.getKey();
// or return the Map.Entry which makes more sense
//return lru;
}
regards,
michael
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
