I will give a longer reply later, but two quick questions:
1) How do you make your tree read-only ? Ex.: A method builds a tree and
returns it as read-only. There must be no way other than using reflection to
circumvent that.
2) How do you handle enumerator versionning ? If I
modify the structure of the tree, enumerators of that tree must be
invalidated. Even better is if an enumerator on a subtree gets
invalidated, another enumerator on a different and independant subtree
will stay
valid as the change is outside of its
scope. The only solution I saw for that last part is that each node
keep a version and changes are propagated up the hierarchy. The cost
of that appears to be quite prohibitive
so I did not bother to try
it and in my implementation, versionning is done at the tree level
only (ie root node).
Sébastien
On 7/27/07, Barry Kelly <[EMAIL PROTECTED]> wrote:
>
> Sébastien Lorion <[EMAIL PROTECTED]> wrote:
>
> > public interface IReadOnlyTree
> > public interface ITree
> > public interface ITreeNode
>
> I understand what you're aiming at, though I have to say that my
> positive experiences with functional styles of programming and my
> negative experiences of the XML DOM have turned me off this kind of
> approach. I think interfaces aren't suited to this. You can't just have
> any old class implement an ITreeNode interface and expect it to live in
> the tree, because to actually implement the interface, it needs to know
> about the concrete implementation of ITree & friends. Thus, you're
> typically forced to go down the tree node factory route, with all its
> associated non-functional-ness and XML DOM horribleness.
>
> By non-functional-ness, I mean: one of the nicest things about trees is
> that they're recursive and eminently suitable to functional-style
> programming. Writing a tree pattern matcher, tree rewriter, etc. is a
> joy when nodes are simple and recursive. Having to go through a
> factory/owner to create nodes, and having to pass that factory/owner
> around, makes writing traversal and rewrite routines a little too heavy
> and Java-y (in the bad, "enterprise" way) for my personal taste.
>
> I'd consider using containment / aggregation, rather than interfaces, to
> get what you're after.
>
> > In the case where the relationships are stored centrally, the nodes are
> much
> > more lightweight in term of code as most operations gets delegated to
> the
> > tree and there is no need to have internal methods.
>
> If the relationships are stored centrally, it seems to me that there's
> no need for your nodes to implement any interface at all - they can
> simply be System.Object. That would appear to me to be a better
> approach; you could then use a proxy class (I'd choose a concrete sealed
> one rather than an interface) to work with the nodes.
>
> Above all, I'd try to avoid generalizing too early. I've come to think
> that interfaces being used pervasively, very early in a design, is a
> sign of too much generalization too soon.
>
> > In the tree-as-a-node approach you describe,
> >
> > I am curious about where exactly you store the relationships between the
> nodes.
> > I get the general idea and it is something I have explored, but
> > I would like to have more details on your implementation.
>
> The nodes store the relationships; typically as either a (possibly
> sparse, i.e. created on demand) List<> of children, or as a FirstChild
> and NextSibling tuple just like a Lisp cons cell.
>
> Here's an idea (using public fields for exposition):
>
> // In library:
> public class TreeNode<TNode> // maybe ': XxxNode' for extra polymorphism
> where TNode: TreeNode<TNode>
> {
> public TNode FirstChild, NextSibling; // or other implementation
> // as you desire
>
> // other stuff for algorithms can be added here without
> // versioning problems interfaces have
> }
> // maybe have different base classes for different implementations
>
> // In user code:
> public class BaseNode : TreeNode<BaseNode>
> {
> // common functionality etc.
> }
>
> public class MySpecificNode : BaseNode
> {
> // ...
> }
>
> -- Barry
>
> --
> http://barrkel.blogspot.com/
>
> ===================================
> This list is hosted by DevelopMentor(r) http://www.develop.com
>
> View archives and manage your subscription(s) at
> http://discuss.develop.com
>
--
Sébastien
www.sebastienlorion.com
