Re: Set and .equals() semantics
Lasse Reichstein Nielsen wrote:
Mark Space <markspace@sbc.global.net> writes:
Nope, I think I agree. Set and subclasses could benefit from a
"find()" method which does an equals() or hashcode() lookup as
appropriate and returns the element already in the set.
That is only relevant if the equality you are using in the Set is not
the equality you are actually working with. I.e., if the instance in
the set and the one you use as a parameter to find() are equal() but
you still want to distinguish them. Otherwise you could just use the
one you have.
That is a special case, and I would think you should create your
own data-structure to handle it instead of complicating Set.
I don't see how canonicalized objects in a Set would help anything. AIUI, the
OP wants to avoid some sort of overhead with retrieval of "heavyweight"
objects. But with a Set.find(), one would need to create the second
heavyweight object to find() the first - what is the benefit? You create the
same number of heavyweight objects anyway. Keeping a Map with these extra
heavyweight keys in them just prolongs their lives and complicates GC.
If one is using the lightweight-type (L) object to look up a heavyweight-type
(H) object, then Map <L, H> is the way to go. Otherwise just create new
instances of the H-type objects at need.
--
Lew