> >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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
