in reply to Heterogenous perl modules
You can do pretty much what you want. I have made simple modules that provided both object methods and exported functions. But I try to avoid such mixing. This practice can easily add to confusion, especially in complex systems.
I prefer to keep my OOP modules separate from my traditional, exporting modules.
If I do have a group of functions that are useful in relation to a class hierarchy, I include them in one or more collections of related utility functions. In other words, the entire module is written for normal procedural use. I also prefer to keep utility functions that are for use by the class hierarchy separate from those intended for use by consumers of the class hierarchy.
My rules of thumb for using OOP are pretty simple. If I have a group of routines that work with a data structure more than 3 levels deep, I always break it up into objects. If I have a group of functions that take the same arguments, I'll probably make an object or objects that encompasses them.
TGI says moo
|
|---|