----- Original Message -----
From: "Michael A. Smith" <[EMAIL PROTECTED]>
To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>;
"Morgan Delagrange" <[EMAIL PROTECTED]>
Sent: Thursday, February 14, 2002 5:12 PM
Subject: Re: [Collections] Comment on LRUMap.removeLRU()
> On Thu, 14 Feb 2002, Morgan Delagrange wrote:
>
> > ----- Original Message -----
> > From: "Morgan Delagrange" <[EMAIL PROTECTED]>
> > To: "Jakarta Commons Developers" <[EMAIL PROTECTED]>
> > Sent: Thursday, February 14, 2002 4:56 PM
> > Subject: [Collections] Comment on LRUMap.removeLRU()
> >
> >
> > > Seems like an odd method (besides the fact that it didn't actually
work
> > > until this week ;) It returns the key of the Object that was removed
from
> > > the Map. Don't you think it should return both the key and the value,
> > > perhaps as an Object[] array? After all, you have no way to use that
key;
> > > the value is already gone.
>
> Why not Map.Entry? :)
Oh yeah, that probably works. :)
>
> > >
> > > Technically, there's nothing we can do about it until Collections 2.x,
but
> > > maybe in the Javadocs we should announce an intention to deprecate it
for
> > a
> > > more appropriate call?
> > >
> >
> > Correction. We could actually deprecate it now and provide an
alternative
> > for the 1.1 release. Any reason not to?
>
> Don't think so, as long as the deprecated method remains supported through
> 1.x. Although if it didn't work until this week, I doubt anyone was
> using/relying on it in the first place.
Someone could have fixed it locally. It's only a 2 character change.
>
> 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.
> Aaron Smuts has a similar method in his LRU cache in Stratum, but his only
> takes one argument (an Object, but it looks like the object that is passed
> in is an ILRUElement, which is very similar to a Map.Entry). He named his
> "waterfall".
>
>
http://cvs.apache.org/viewcvs.cgi/jakarta-turbine-stratum/src/java/org/apach
e/stratum/util/lru/LRUStore.java?rev=1.1&content-type=text/vnd.viewcvs-marku
p
>
>
> regards,
> Michael
>
>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
