commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jack, Paul" <>
Subject RE: PATCH : org.apache.commons.collections.SoftRefHashMap
Date Tue, 21 May 2002 17:59:30 GMT
> Well, the existing "purge()" method iterated through the 
> whole Map checking 
> each reference so see if it had been cleared. The new 
> "purge()" method 
> simply calls "processQueue()". This does not iterate through 
> the whole Map, 
> but instead uses the ReferenceQueue to directly get the 
> references that have 
> been cleared and remove them from the Map. This should be 
> much quicker.

I agree that a ReferenceQueue improves performance, but why
deprecate the public purge() method?

> Backwardly compatible? The class is broken as it is! People 
> whose code 
> extends the current version doesn't work anyway...

The entrySet() and values() methods are broken, and should
be patched; the createReference() method works fine,
and there may exist perfectly valid code that requires it. 

> The functionality is questionable not only because 
> composition should be 
> favoured over inheritance; it seems madness that I can extend 
> a class called 
> SoftRefHashMap to NOT be a SoftRefHashMap.

"Madness?"  That's a bit extreme.  I agree the name is misleading
but that could be easily addressed in the documentation, without
breaking anybody's code.

And there are also ways of migrating to a composition pattern
that wouldn't require breaking compatibility.

> The extra "subclass-able" functionality CANNOT exist in my 
> implementation 

Couldn't you use a specialized subclass of ReferenceQueue?

> To be fair, given that my PATCH is actually a faithful 
> implementation of the 
> Map interface and the current class is not, I don't see the 
> problem - you 
> would be replacing a broken class that has some unnecessary 
> and questionable 
> functionality with a working version without it. Surely where 
> someone has 
> used a bad design in this instance, the problem can be rectified.

Again, only the values() and entrySet() methods are broken.  By
all means, we should patch them.  But existing functionality that
works, and that people might rely on, should remain.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message