commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <>
Subject Re: [Collections] TreeNode, TreeIterator, IdentityHashSet proposed collections
Date Sat, 06 Apr 2002 23:17:06 GMT
> >Related to this is the question of hashCode and equals methods. (The
> >type of collection is a Set, which needs a hashCode). So far, my view is
> >use the == check for equals and the identity hashCode (ie. don't
> >either method).
> These sounds better than the alternatives you examined and rejected. Have
> you looked at how the Sun or other commons collections implement these?

List and Map both perform equals() by looping around all their contents
comparing values. As I said before, a value only comparison won't do for
TreeNode because it ignores the structure. (Something different might be
possible for Tree, because the keys enable quick access to the whole tree).

> >...we should really
> >have a better toString() implementation anyway - more collections like -
> >including a list of the children.
> Yes, I agree the overhead of reflection isn't appropriate for toString.
> cache the string value (list of children), and update it when new children
> added? Each node could maintain a string list of its children, and when it
> changes it, trigger its parent to do the same.

I think even that is more than we need, how about
TreeNode[x children,value=y]
as a format for TreeNode's toString()?

I have tweaked our two sets of interfaces tonight to produce a combination
that starts to hang together. I don't think I lost any functionality, but
they are only the interfaces at the moment. See what you think at


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

View raw message