> A rough sketch of the interface, which admittedly follows the architecture
of
> my own implementation more than yours, would be like:
>
> public interface Tree extends Collection {
> /** Throws an exception if the parent isn't in the Tree already. */
> boolean add(Object parent, Object child);
> boolean addToRoot(Object child);
> boolean addAll(Object parent, Collection children);
> Iterator children(Object parent);
> Iterator rootChildren();
> /** All values in the Tree */
> Iterator iterator();
> }
>
> It would need to be fleshed out, but at this level wouldn't assume
anything
> about ordering, so for instance a get(Object parent, int position) method
> would be instead added to a ListTree interface. A SetTree could either
> guarantee that a value appears only once in the Tree, or else would just
> guarantee that it only appears once as a child of any particular node.
> MapTree would map each value to a unique key, unique either for the tree
> or perhaps just for a given node. My current implementation has keys as
> unique across the Tree, but that's too restrictive.At this point, I was starting to get confused, so I went back and looked at your initial Tree, TreeEntry and StandardTree classes. I realised that the difference between the two implementations is that you view the tree as a single 'flat' collection (which happens to be a Map). Tree allows the values to be added and removed without ever really knowing much about the structure of the tree. In fact, you go further in your Javadoc and say that applications shouldn't know about the TreeEntry class. My implementation views the tree as nodes - there is no single object representing the whole tree. Thus my TreeNode class corresponds most closely to the TreeEntry class of yours, not Tree. The value must be manually obtained by the application from the TreeNode class. I have had a go to see if I could rearrange Tree to be a flat view over TreeNodes and extend Collection. So far I have failed. It seems to me to be related to the issue as to whether Map should have extended Collection. It could have done, but the restriction would have been that all objects in the collection were Map.Entry. Tree is more complex. I considered a what-if extrapolated from Map: What if Tree extended Collection with the restriction that the only objects that could be added are TreeNodes. Unlike the Map case, this does not solve the problem, because the 'state' of the tree (parent/children) is held in the TreeNode being passed in. There is nothing left for the add() method to do. So, the one thing I don't understand is the desire to use Map and keys as part of the tree design. Can you explain the reasoning behind this? I currently think that they exist because you chose not to expose the TreeEntry class to the application, but I could be wrong. Stephen -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
