Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org Received: (qmail 75291 invoked from network); 14 Aug 2004 00:01:32 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 14 Aug 2004 00:01:32 -0000 Received: (qmail 66650 invoked by uid 500); 14 Aug 2004 00:01:29 -0000 Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org Received: (qmail 66599 invoked by uid 500); 14 Aug 2004 00:01:28 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 66584 invoked by uid 99); 14 Aug 2004 00:01:28 -0000 X-ASF-Spam-Status: No, hits=1.6 required=10.0 tests=DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST X-Spam-Check-By: apache.org Received: from [217.12.12.197] (HELO smtp807.mail.ukl.yahoo.com) (217.12.12.197) by apache.org (qpsmtpd/0.27.1) with SMTP; Fri, 13 Aug 2004 17:01:26 -0700 Received: from unknown (HELO oemcomputer) (commons-dev@jakarta.apache.org@217.43.117.223 with poptime) by smtp807.mail.ukl.yahoo.com with SMTP; 14 Aug 2004 00:01:22 -0000 Message-ID: <006c01c48192$3bf77d20$df752bd9@oemcomputer> From: "Stephen Colebourne" To: "Jakarta Commons Developers List" References: <1092337789.2436.96.camel@DaVinci> Subject: Re: [Collections] A new collection for consideration - Map based Tree Date: Sat, 14 Aug 2004 01:04:13 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N 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" > 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 > 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