If a module doesn't need to keep track of state information at all between "methods"/functions, you generally don't want to use an object-oriented approach. If it's possible/likely that the user (the developer) will want to create multiple objects/sets of state information and manipulate each set individually, an object-oriented approach is pretty much a must.

For stuff in between, though, don't underestimate the value of passing arguments to simple functions, exported by your module. If you feel that your module will easist to use in a functional capacity, but you'd still like to offer the developer the ability to create objects, why not just write your module to support both methods (a la CGI.pm)?

For example, DBI needs to use objects. Without them, we would be unnecessarily preventing the developer from working with two databases at the same time. Array::Compare, however, does not need to use objects (it does!). Why do we need to instantiate a "comparator" object to perform our array comparisons? A function, with perhaps optional arguments, would be a lot easier to use and read. Plus, it would allow us to use function prototypes if we felt the need (a plus in Array::Compare's case, for instance).

So don't jump on the OO train just because it's a nifty way of doing things. If your code would benefit functionally from using objects, or you have a need to keep track of isolated state information, fine, but weigh your module's usability against power and try to look at both ends of the spectrum.

Personally, I feel that some modules nowadays are trying to use objects because it's "cool", even though the module would be better off being used in a functional manner.

My dear Fastolfe, thou are a bit slow: modules serve to encapsulate variables, even for a collection of related functions. 'tis not only for OOP that thou wilt find modules of great use in parting the red seas of programming jobs that lies ahead for ye.

Hmm.. Maybe one of us is misunderstanding the other.. I have no problem with modules, I just have a problem with the overuse of OOP in cases where it just adds complexity without any benefit. Consider some module "Object", which has the sole task of performing some_operation on $item, the behavior of which could change, depending on the value of some_variable.

use Object;
my $obj = new Object;
$obj->some_operation($item);
$obj->some_variable($argument);
$obj->some_operation($item);

# versus

use Object;
some_operation($item);
some_operation($item, $argument);
[download]

In my opinion, there are many types of modules that, for whatever reason, unnecessarily go with an OO approach, even though the paradigm doesn't quite fit, and we get little benefit out if it. I really don't know how to describe the best way to decide. For me, I just look at my package in both ways. If it "feels" right in an object point of view, if I can see a benefit to creating multiple "instances" of my module in the form of objects and toss those around, I'll build it in OO style. If my resulting implementation is going to be a lot more efficient and simpler in a functional style, I'll go that route. Perhaps it's just personal preference...

• a single variable that really has nothing to do with any others (waste of time to throw in a class with various protections that I can keep track of myself
• or a bunch of random variables that have nothign to do with each other and would be otherwise lonely variables (it wouldn't make sense to bundle them together)
• functions I'll be using alot (skipping a class name may save me typing in the long run:-O)
• global variables that I'll be using alot that are encapsulated in their own right (like my own personal %configuration hash).

AgentM Systems nor Nasca Enterprises nor Bone::Easy is responsible for the comments made by AgentM.</h6>