Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical

Re: Can I please have *simple* modules?

by dragonchild (Archbishop)
on Nov 23, 2005 at 16:52 UTC ( #511172=note: print w/replies, xml ) Need Help??

in reply to Can I please have *simple* modules?

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.

  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.

My criteria for good software:
  1. Does it work?
  2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
  • Comment on Re: Can I please have *simple* modules?

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://511172]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (11)
As of 2017-10-20 13:20 GMT
Find Nodes?
    Voting Booth?
    My fridge is mostly full of:

    Results (263 votes). Check out past polls.