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 functions1
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.
- 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.
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
Outside of code tags, you may need to use entities for some characters:
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.
| & || & |
| < || < |
| > || > |
| [ || [ |
| ] || ] ||