If you search the mailing list you will see previous discussions about Tree based structures. The big problem seems to be that everyone wants something slightly different, so I'm not certain there is common ground.
That said, the code you present appears to be a good idea, and seems reusable (although I can't think of a good use case right now). (Can you explain your use case?) Ideally, I would like to see a Tree or TreeNode interface with various implementations (see previous attempts in archive). Have you any comments about alternate Tree implementations? I am also unconvinced about implementing Map. Finally, you should compare this with MultiKeyMap, as the two do seem to overlap. The position with [collections] is that it needs to work on the basis of smaller more focussed deliveries. This may be achieved using multiple commons projects, or multiple jars delivered by collections. For the moment, this code may be best in the sandbox, to see if a generic Tree interface can be created. Stephen ----- Original Message ----- From: "Michael Stover" <[EMAIL PROTECTED]> > You can view the code I'm talking about at: > http://cvs.apache.org/viewcvs.cgi/jakarta-jmeter/src/jorphan/org/apache/jorp han/collections/ > > Ignore Data.java. I'm primarily interested in HashTree.java > > HashTree is essentially a Map of Maps. I've looked through Collections > and not found such a thing (CompositeMap seems to be something else > entirely). HashTree holds a tree of values and provides a lot of > methods for manipulating those values. It's not unlike a DOM, except it > has nothing specific to XML or anything else - it works with objects > just like a Map does, and it provides better ways to access and store > values. > > For instance, to add a value(s) deep into the tree, I can do: > > tree.add(path,value) > tree.set(path,value) > tree.add(path,collection) > tree.set(path,object[]) > > This will traverse the given path (a Collection or object[] or a single > object) and add the value as a leaf at the end, or add the entire list > of values at the end of the path. > > I can get a list of values anywhere in the tree: > > tree.list(path) > or tree.getArray(path) > > I can search a tree via search(object) and get back the Tree headed by > that element. > > Perhaps best of all, there is a HashTreeTraverser interface that let's > one define more complex activities that can be done to a tree without > having to write any traversal code. The tree will traverse itself > depth-first and execute callbacks to the HashTreeTraverser. This is how > Search is implemented, and it's also how toString() is implemented (you > can see the inner classes in the code that implement HashTreeTraverser > to do this). > > There is also a ListedHashTree implementation (ie an OrderedMap) and a > SortedHashTree, and a SearchByClass implementation of a > HashTreeTraverser. I imagine people will want to change the names and > it would be nice to define an interface for it, which is all fine. > > Any interest? > > -- > Michael Stover <[EMAIL PROTECTED]> > Apache Software Foundation > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
