> > Which suggests the right approach to take is to > leave TreeNode as it is, > and consider whether to make an implementation of > Tree that uses TreeNode > for its guts. > > This was kind of where I was heading. What if the > keys in your > implementation became TreeNodes?
I'm not sure I see the point? I think TreeNode ought to simply replace TreeEntry. A basic implementation of Tree would just provide a Collection-based interface (in the general sense of the word, not the Java sense) for accessing TreeNodes, no use of keys. For my application which uses keys, I would subclass TreeNode to include a key field. The key-based tree should be an extension of the non-key-based tree (as James Strachan suggested). But there's no reason to use keys in the base implementation. Let me explain why am I using a keyed Map. My application stores a tree structure in a database, a hierarchy of topics under which content items can be posted (think Yahoo directory). When I build my tree, I use the primary key field from the table as the key, and I link children and parents based on a references (i.e. a self-referencing parent_id field in the table). HTML links for navigating the directory use this ID to identify the node in the directory, so being able to do a Tree.get(id) to get the node is convenient. I'll start drafting up some code for this. Kief __________________________________________________ Do You Yahoo!? Yahoo! Greetings - send holiday greetings for Easter, Passover http://greetings.yahoo.com/ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
