My votes: 1. Eliminate TreeIterator. 2. Eliminate equals(), hashCode() and clone() from TreeNode. 3. Have iterator() make no guarantees about order; provide the utility methods for depth-first and breadth-first.
Should the children be represented by a List or by a Collection? Seems GUI trees would usually want their children sorted, so the ability to add a child at an arbitrary index would be bad (you could manually muck up the sort order which could cause algorithms expecting the List to be sorted to fail). -Paul > -----Original Message----- > From: Stephen Colebourne [mailto:[EMAIL PROTECTED]] > Sent: Monday, May 27, 2002 11:19 AM > To: Jakarta Commons Developers List > Subject: Re: [Collections][Submit] TreeNode and friends > > > From: Kief Morris <[EMAIL PROTECTED]> > > >I would rather keep the iterator on TreeNode. If there are only two > standard > > >ways to iterate then two methods would seem appropriate. > But are there > more > > >than two ways?? > > > > I favor a single iterator() method on the interface which > returns the > nodes in an > > unspecified order. I'm ambivalent about having the specific > breadth/depth > iterator > > methods on the Interface, but if it seems like there will > be more than > that, forget > > it; keep just a single iterator() method and leave other options to > implementations > > rather than clutter the interface. > > > > There's nothing wrong with having a plain iterator() method even if > there's no > > default way it needs to be implemented; other Collection (non-List) > classes > > have iterators whose return order is unspecified. > > Good argument. How about: > > "iterator() returns an iterator over the tree including this > node and all of > its children. For specificly ordered iterations, use the > methods provided on > TreeUtils." > > Thus we have an iterator() method on TreeNode and > depthFirstIterator(TreeNode) and > breadthFirstIterator(TreeNode) methods on > TreeUtils. > > The other related question is whether to use TreeIterator, or > just Iterator. > TreeIterator really only provides a typecast nextNode() > method. Is this > enough to justify its existence? > > Stephen > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
