Tree::DAG_Node may look like overshooting, but it does what it promises, i.e. a simple way of dealing with complex tree structures. I share your chagrin about lack of tests, but having seen that knowledgeable people like merlyn and perrin use it, I feel confident that it must not be as bad as you may think.

A simple example that makes me love this module:

#!/usr/bin/perl -w
use strict;
use Tree::DAG_Node;

my $tree =
[
        [
            'Node1'
        ],
        [
                [ 'GrandChild1' ],
                [ 'GrandChild2' ],
            'Node2'
        ],
  'Root'
];

my $dagnode= Tree::DAG_Node->lol_to_tree($tree);
print map {"$_\n"} @{ $dagnode->draw_ascii_tree };


__END__
And the output is:

                |
              <Root>
   /-----------------\
   |                 |
<Node1>           <Node2>
              /-------------\
              |             |
        <GrandChild1> <GrandChild2>
[download]

There is also a nice Introduction to Tree::DAG_Node in Tutorials.

I share your chagrin about lack of tests, but having seen that knowledgeable people like merlyn and perrin use it, I feel confident that it must not be as bad as you may think.

While I have the plenty of respect for merlyn and perrin and their collective experience, I don't take their choices on blind faith (that is not say that you are). I also know that Tree::DAG_Node seems to have been (for the most part) the only choice out there (the last version of Tree::DAG_Node was released in 2001 and the first version was released in 1998). Tree::DAG_Node does a lot too (IMO it tries to do too much), and I am sure people were reluctant to have to implement that themselves, so it was better to just use it, however that doesn't mean that it was always the best choice.

And as for the lack of tests, for me this was the deal breaker. The application for which I originally developed Tree::Simple used tree structures as a fundemental component which was at the lowest levels of the application. I needed a n-ary tree which was well tested and that I was confident would work as I needed it to. Tree::DAG_Node just did not fit this description for me.

A simple example that makes me love this module:

I agree with you, I simultaniously like and dislike how much you can do with Tree::DAG_Node. It is all good functionality, but I think its too much packed into one module. My goal with Tree::Simple is to provide all the same functionality (and more) but with a more modular and flexible design. Tree::Simple::VisitorFactory is inteneded to be a means of adding functionality which really does not belong in Tree::Simple, while Tree::Simple::View is intended to help keep the display layer seperate (it has an HTML and DHTML version, and I am working on a Tk version too). I also working on a Tree::Visualize module, which currently draws Tree::Simple and Tree::Binary trees in ASCII and with GraphViz in a number of layout styles (top-down like DAG_Node does, as well as others).

IMO all these things should be in seperate modules, not all squished into one.

-stvn

I am hesitant to write Visitors to convert from one Tree:: module to mine, as it sort of feels rude to do so.

I wouldn't worry about it that much, there's nothing wrong with providing good tools and a a flexible API. If it eases your conscience, provide code to convert both ways.

If it eases your conscience, provide code to convert both ways.

Excellent point, thanks.

-stvn