From: Jack, Paul <[EMAIL PROTECTED]> > My votes: > > 1. Eliminate TreeIterator.
This seems to be sensible, given it just provides a typecast. > 2. Eliminate equals(), hashCode() and clone() from TreeNode. I think I'm happy with clone() being removed, but equals() and hashCode() need to be present to document their behaviour (java collections do this too). > 3. Have iterator() make no guarantees about order; provide > the utility methods for depth-first and breadth-first. This seems to be the consensus, and I'm happy with it. > 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). I think that the children of a node are generally ordered. Swings TreeNode uses indexed access. A Binary Tree sounds indexed to me (0 and 1). XML trees have ordered children. Collection doesn't guarantee order (Set can return its children in any order in the iterator) So I think a List is appropriate here. Were there any particular cases you thought of? Stephen > -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]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
