From: Kief Morris [EMAIL PROTECTED]
Stephen Colebourne typed the following on 12:17 AM 4/7/2002 +0100
I have tweaked our two sets of interfaces tonight to produce a
combination
that starts to hang together. I don't think I lost any functionality, but
they are only the interfaces at the
Sorry for the delay in responding, too much going on outside the coding life.
Stephen Colebourne typed the following on 12:49 AM 4/2/2002 +0100
I would suggest it would be better to keep the list
holding the children better hidden from the user.
Children can be added and removed with methods
Related to this is the question of hashCode and equals methods. (The
other
type of collection is a Set, which needs a hashCode). So far, my view is
to
use the == check for equals and the identity hashCode (ie. don't
implement
either method).
These sounds better than the alternatives you
I realised that the
difference between the two implementations is that
you view the tree as a
single 'flat' collection (which happens to be a
Map). Tree allows the values
to be added and removed without ever really knowing
much about the structure
of the tree. In fact, you go further in
I realised that the
difference between the two implementations is that
you view the tree as a
single 'flat' collection (which happens to be a
Map). Tree allows the values
to be added and removed without ever really knowing
much about the structure
of the tree. In fact, you go further in
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
Stephen, I have some questions/suggestions on your
TreeNode implementation.
It looks like ArrayTreeNode expects users to access
and manipulate the children of a node by returning a
List from getChildren(), which users then use to add,
delete, and access the child nodes. I don't think this
It looks like ArrayTreeNode expects users to access
and manipulate the children of a node by returning a
List from getChildren(), which users then use to add,
delete, and access the child nodes. I don't think this
follows best practices as seen in the java.util
collections and other commons
Thus my TreeNode class
corresponds most closely
to the TreeEntry class of yours, not Tree.
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
Stephen Colebourne typed the following on 02:59 PM 3/29/2002 +
We ought to make a common interface for both versions, which would look
more like your TreeNode than my Tree, although I suggest we name it Tree.
...
Makes sense in theory, but the main problem that I foresee is that it is not
A rough sketch of the interface, which admittedly follows the architecture
of
my own implementation more than yours, would be like:
public interface Tree extends Collection {
/** Throws an exception if the parent isn't in the Tree already. */
boolean add(Object parent, Object child);
Stephen Colebourne typed the following on 10:27 PM 3/28/2002 +
As part of the Joda project (www.joda.org) I have developed the following
collections that I would like to propose for inclusion in Apache commons
collection:
1) TreeNode, ArrayTreeNode and TreeIterator
12 matches
Mail list logo
