I think rafl's reasoning for suggesting OO was that the general operations were similar, but there were slight variations, depending on the situation. That's a situation where PBP says using OO would be appropriate.

However, TheDamian also says to make OO a choice, not default. In a nutshell (my paraphrasing of pp. 320-321), if you have

• a large-scale, enterprise-type environment
• that changes often and
• where programmers are using OO

or your data

• is hierarchical,
• requires operations that are similar one another

it may benefit you to use OO. Oh, there were a couple situations in the book I left out, but that should give you the gist of it.

---

Also, I'd highly suggest using Perl6::Export::Attrs in writing your modules. I could never remember the syntax for writing a module, and it was a major reason why I hadn't gotten around to refactoring my code into modules, until recently. But with this, it's a lot simpler - you just specify the module with a 'use' statement, and specify :Export in your subroutine if you want it exported from the module. Example:

package myModule;

use Perl6::Export::Attrs;

sub DoSomething :Export {
      #whatever 
}
[download]

Of course, you can specify more, but you can look at the docs for that. This code should get you started. Oh, and you don't need to install Perl6 itself to get this, by the way; I've been using it fine on 5.8.7 and 5.6.