> Stephen Colebourne typed the following on 10:27 PM 3/28/2002 +0000 > >As part of the Joda project (www.joda.org) I have developed the following > >collections that I would like to propose for inclusion in Apache commons > >collection: > > > >1) TreeNode, ArrayTreeNode and TreeIterator > >http://www.scolebourne.eurobell.co.uk/JodaTreeProposal.zip ... > I've had a look over TreeNode, I think they're not so different that they > can't be tied together to share some of their interfaces and maybe some > code. The essential difference is that my version stores objects using > keys, like a map, while yours keeps them list-style. It makes sense to > me to have both, since yours is more fundamental, and my key functionality > is just an extension of the concept.
Sounds good. > We ought to make a common interface for both versions, which would look > more like your TreeNode than my Tree, although I suggest we name it Tree. > Then my interface would extend this interface, and be called MapTree or > KeyedTree. Your implementation, ArrayTreeNode or maybe just ArrayTree, > would be the basic implementation, and my implemention would subclass > it. If this turns out to be impractical, we can make an abstract class with > common code, which both versions would then subclass. Makes sense in theory, but the main problem that I foresee is that it is not possible to have a single class that implements both Map and Collection/List. I don't know how that would affect your implementation. Maybe it just means that your implementation won't implement Map, but will still have the same methods. > One question I have about your implementation: is there a reason you didn't > implement the java.util.Collection interface? It would make it more compatible > with other collections code. This was one of the questions about my design. The children of a given tree node can be held as a property of the node, or the node itself could be a list of children. If we did extend Collection, what would add() mean? If it means adding children, then TreeNode/Tree should probably extend List not Collection. > Once the current commons-collections release is out maybe we can get > this added so we can hash it out. Agreed. I think a collections Tree implementation is a good thing. Stephen FYI, the class was created to represent beans in a tree like structure so I could iterate over them. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
