This is the very reason I wrote Tree and am taking over maintainership of all of the main Tree::* modules so I can deprecate them. My theory behind it is that the main module should do the simplest thing possible to implement what needs implementing. Then, when you want to customize it, it should be customized very easily. For example, stvn pointed me to DBIx::Roles (which is really DBI decorators, not roles). That provides a really good framework within which an author can release DBIx functionality in a way that plays nicely with other DBIx functionality. Tree does this by providing five functions¹ that, with options, does everything you want to do to a tree data structure. It also provides an events/callbacks framework that Tree::Persist uses to implement transparent persistence. It also provides a place to put arbitrary data that Tree::Compat uses to implement compatibility layers for the various modules I'm taking over.

DBI v2, from what I understand, will be moving in this direction. So is CGI::Application with the plugins architecture. The Class::* namespace is a mess, in large part because Perl5's OO framework is too minimal. That's why I didn't use one when writing Tree - I didn't want the dependency on something that fundamental when it was easy enough for me to avoid it. It may not be so easy for others, especially a well-developed distribution.

You're right - this is a hard problem which doesn't admit of an easy answer. Things will be easier in Perl6 (as they currently are in Ruby) where you will be able to require a name, version, and author (plus arbitrary metadata). Then, you can fork your distribution, release it to CP6AN, and then depend on it based on author. When your fork is folded back into the main branch, you can release an update that now points at the main branch with the appopriate version and author.

Once that comes into play, if I don't own the module, I will probably require the exact version I built with for modules I don't own. Because installing versions side-by-side won't be a problem, that will probably be safest.

1. Those are new, add_child, remove_child, traverse, and set_value. There's a large number of state-inquiry functions, like is_root, is_leaf, parent, children, root, depth, height, width, size, etc, but those don't do things. Everything else can be implemented in terms of those functions, and I provide an example of this (implementing a visitor) in the documentation. So, for example, I didn't write add_child_before() or add_child_with_value() or any crap like that.

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.