commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@eurobell.co.uk>
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
other
> >type of collection is a Set, which needs a hashCode). So far, my view is
to
> >use the == check for equals and the identity hashCode (ie. don't
implement
> >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.
Maybe
> cache the string value (list of children), and update it when new children
are
> 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
http://www.scolebourne.eurobell.co.uk/Tree1.zip

Stephen




--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message