The reason you should use a module is because someone else much smarter than you has figured out the stupid details so that you don't have to learn it, understand it, and remember it. More importantly, when the stupid details change (as they always will), you don't have to even be aware that they changed. The module will DWIM and life will be good.
Let's take your example. Others have already mentioned dealing with timezones and other headers being outputted. I'm going to go further and say "What if you're potentially not always dealing with HTML?" Sounds stupid? Maybe not ...
I'm starting to design a Data-Access Layer (DAL) for interfacing two completely disparate applications (one in Perl, the other in Java) onto the same database. For ease of development, I'm going to use Apache as the server and use XML as the messaging structure. It will be very HTTP-like in that the client will send a request and the server will send a response. I can see using the concept of cookies to aid usage of the DAL from both the Perl and the Java sides. Maybe, a CGI-like module is written to use the same interface?
Ok, maybe that wasn't as believable. But, how about this one? I just wrote a generalized datastream handler. It doesn't make any assumptions about the type of the file, if you give it a filehandle. This allows me to use IO::File, IO::Zlib, and any other IO::* module, plus typeglobs and stuff returned by open().
Modules provide interfaces. If two modules conform to the same interface, they can be treated the same way. This is why IO::All is so powerful (and is even possible!)
------
We are the carpenters and bricklayers of the Information Age.
Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.
In reply to Re: When to use modules?
by dragonchild
in thread When to use modules?
by wolfi
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |