If that thing was a class,

Before I start writing a class module to do something I usually ask myself a few questions:

• Is this thing complicated enough to justify the overhead?
  While there isn't much overhead in a module given that a module can be as simple as:

  package Foo;
  1;
  [download]

  but a properly written module does have some inherent overhead to it. For one thing if you are going to write a module then it deserves to have pod embedded into it so that six months later when your smoking a different brand of crack you can remember why you wrote the module and how it works.
• Am I going to use this again?
  I am forever writing modules that I think I'm going to use later and disappoint myself when I don't. Worse I forget that I wrote the darn thing and I write another one that does the same thing. But that's me. I suffer from C.R.A.F.T. and get like a squirrel burying nuts at times.
  If you are going to go to the trouble of writing a module make sure you're going to get use out of it.
• Is someone else going to use this?
  If I am writing code at work I normally presume that someone else may use it down the line. If it is a Perl programming gig then there is absolute certainty about this. This makes for an even larger burden to make sure that this module is useful, properly crafted, and properly documented. If you are coding in a corporate environment then there may be programming and documentation standards for you to adhere to. If not maybe you can pioneer them with buy-in from your management and other members of your team.

From other folks comments and what you described to me this is not a good candidate for a separate module and could in fact obfuscate your code. That's abuse of the module system in my opinion. :-)

If you get to the point you are writing modules that the larger Perl community can benefit from consider becoming a contributor to CPAN.