Re: [Collections] A new collection for consideration - Map based Tree

[Stephen Colebourne <sc...@btopenworld.com>]

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" <ms...@apache.org>
> 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 <ms...@apache.org>
> Apache Software Foundation
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org