Re: Set and .equals() semantics
On Fri, 9 May 2008, Patricia Shanahan wrote:
Jaakko Kangasharju wrote:
As a simple example, consider a Set of Characters implemented as a bit
array, which is allowed by the Set interface. The original Character
objects aren't stored anywhere, only bits indicating whether they've
been added, so while you could implement a find method for it, it would
(at least in many cases) return a different object every time.
Along this line, I've sometimes considered writing a BitSet wrapper that
would implement Set<Integer>.
However, I am unsure whether iterator() is allowed to return references
to objects that are merely equal to the ones that were added, or must
return references to the actual objects.
Surely not. If it was, collections that are implemented on top of
persistent stores, eg as an interface to DBM, would be illegal.
Although such collections would hopefully use weak-referenced cacheing, so
that when they do return a brand new object, it's because there's no
equivalent object in existence, which would mean there's no way to tell
they've done it. Which might make it a bit more okay.
Oh, for hash-consing ... :)
tom
--
.... but when you spin it it looks like a dancing foetus!