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 joda.org 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. Kief -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
