Stephen Colebourne typed the following on 02:59 PM 3/29/2002 +0000
>> 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
>possible to have a single class that implements both Map and
>Collection/List. I don't know how that would affect your implementation.
>Maybe it just means that your implementation won't implement Map, but will
>still have the same methods.
Doh, you're right. I guess it's got to be a Collection. List doesn't seem right,
since all of the items have to be strictly ordered, allowing the user to do a
list.get(int), for example. Map doesn't work for the general case: even we
designed it with methods such as add(parent, child), which looks map-like,
each key of a Map is only supposed to have one value.
>This was one of the questions about my design. The children of a given tree
>node can be held as a property of the node, or the node itself could be a
>list of children. If we did extend Collection, what would add() mean? If it
>means adding children, then TreeNode/Tree should probably extend List not
>Collection.
Well, implementing add() is an optional operation for a Collection, we could
just throw an UnsupportedOperationException if it doesn't fit our design.
Alternately, add() could just add the value to the root of the Tree.
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);
boolean addToRoot(Object child);
boolean addAll(Object parent, Collection children);
Iterator children(Object parent);
Iterator rootChildren();
/** All values in the Tree */
Iterator iterator();
}
It would need to be fleshed out, but at this level wouldn't assume anything
about ordering, so for instance a get(Object parent, int position) method
would be instead added to a ListTree interface. A SetTree could either
guarantee that a value appears only once in the Tree, or else would just
guarantee that it only appears once as a child of any particular node.
MapTree would map each value to a unique key, unique either for the tree
or perhaps just for a given node. My current implementation has keys as
unique across the Tree, but that's too restrictive.
Kief
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
