commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kief Morris <>
Subject Re: [Collections] TreeNode, TreeIterator, IdentityHashSet proposed collections
Date Sat, 06 Apr 2002 18:46:17 GMT
Sorry for the delay in responding, too much going on outside the coding life.

Stephen Colebourne typed the following on 12:49 AM 4/2/2002 +0100
>> I would suggest it would be better to keep the list
>> holding the children better hidden from the user.
>> Children can be added and removed with methods such as
>> TreeNode.addChild() and TreeNode.removeChild(). 

>True, provided you only go down one level. By hiding the created child node,
>you cannot add any children to it, which is a bit of a problem.
>> A List or Collection of children can be returned from
>> TreeNode, but should be a defensive copy of the
>> internal list.

>I disagree. A dead copy means less to implement, but means we end up adding
>all the List methods to TreeNode. I would suggest that by using a live list
>of children we enable applications to use the full interface of List to
>manipulate that list of children, such as subList() and retainAll() that
>wouldn't be available otherwise. Having an addChild(TreeNode) method on
>TreeNode may well be a good idea for ease of use however.

OK, I'm still uncomfortable with the design, but I see the reasons for it. Having 
both the internal nuts and bolts interface of TreeNode and the smooth locked-down 
interface of Tree available sounds better and better the more I understand the
practicalities of your approach.

>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?

>> A question, in ArrayTreeNode.toString() you use a
>> method called Reflection.getShortenedClassName(),
>> which I don't have anywhere in my system (using JDK
>> 1.3). Where does this come from?
>Another of my utilities is a set of reflection utilities. In this case the
>code got the class name minus the package name (which ironically doesn't use
>reflection!). Its available on if you want it, but 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. 


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

View raw message