Doing fancy traversal thingies.

Tree::Simple::Visitor provides a pre-order traversal, Tree::Simple::VisitorFactory provides a post-order traversal as well as breadth-first traversal. All have been thoroughly tested with approx. 90%+ code coverage. If you need a binary tree, I also wrote Tree::Binary, which has pre-order, post-order, in-order and breadth-first traversal Visitor objects as well.

Here I'd write a specialized Node class,...

Tree::Simple makes no assumptions about your node, you can store anything you like in the node value slot (provided of course its a scalar value or reference). All Tree::Simple really does is create the structural relationship between itself and its children and its parents.

no visitor factories or view classes or other mega-designed stuff (I don't believe in such things ...

To each their own, it is your choice. But I disagree that these things are "mega-designed". They are smart patterns, written down by very smart people because they found that enough other smart people they knew followed them (or something similar to them). Patterns may feel like "over-design" at times, but the fact is that they do make a lot of sense in a lot of cases to a lot of people. I wouldn't dismiss them so readily if I were you.

Also keep in mind, that my intention was not to "over-design", but to try and keep seperate concerns seperate. If you don't need it, you should not have to use it (compile it, pollute your namespace with it, etc.) And really, the Visitor factory is really pretty small, 23 lines of code, and 3 methods. Its really just a way to prevent having to write long module names. The View classes (i assume you are talking about Tree::Simple::View) are very simple to use, you can get a full expanding and collapsing DHTML tree in approx. 1 line of code using it. The goal here is not to get the Software Design of the Year award, but to make it easy for the user to get the most functionality with the least code.

I'm a control freak.

Me too, thats why I wrote Tree::Simple instead of used Tree::DAG_Node.

Anyhow, I rarely need to do this for commercial/work type programs, this is usually a "for fun" type of endeavor, and when I do things for fun, I like to do as much as possible myself.

I agree, it is rarely as much "fun" to use a module, as it is to figure it out on your own.

If you are writing a tree class,

already did :)

it might be nice to have restricted modes for trees of fixed/variable node-size,

This can easily be done with a subclass of Tree::Simple.

... red-black trees, ...

I think this is better done as it's own module, rather than try to squeeze it in with a basic n-ary tree.

and heaps.

Again, better as another module IMO. Although as I suggested to FoxTrotUniform above, maybe that would work as a Visitor too. To be honest, my experience with heaps is limited.

You may also want to have optional up-pointers.

Tree::Simple has a getParent method already. For my needs, this was critical to have.

You might also want to generalize your base class nodes for graph usage.

Well there is Graph out there already (which I have not examined all that closely). And while a tree is really just a specialized graph, I think maybe it would be over-generalizing it to go that far. I would suspect that in the end the base class would not be able to effectively serve all the specialized types of graphs out there.

You might like classes that run minimax with alpha-beta pruning on a tree.

I wrote Tree::Binary::Search, which has both a min and a max function. And while that may be useful in some n-ary tree situations, I think it is best not included in the base class, but in a Visitor :)

But it sounds to me you aren't trying to make a Tree::Simple, you are trying to make a Forrest::VeryComplex.

Tree::Simple is intentionally very basic, which is why all the Visitor classes. They allow me to offer complex functionality without polluting Tree::Simple with too many methods and responsibilities.

Decide what you want, and do it. I don't think a Tree::Simple should concern anyone about visitor patterns, factories, and views, but that's just me.

But my goal is not to just "do what I want to do", but to offer others code they can use. You need not concern yourself with visitors, factories and views in order to use Tree::Simple. You can just use Tree::Simple and forget about all the other stuff. However, then you need to implement all that functionality on your own. They are just additional tools to make my (and maybe your) life easier.

I usually shudder when I see design pattern terminology. I avoid it like the plague.

Well, this is your choice.