I don't want to get too much into theory or start any holy wars, so I'm going to stay on the "safe side" with this.
Just what should a perl module do?
In generaly, any set of functionality that is likely to be used by more than one other script or module can and should be put into a module package. You can further use namespaces to logicially organize functionality. What comprises a 'set' of functionality is a matter of diverse opinion, but the important thing is to decide on a definition and stick with it for a given project.
An example of how I do things may be helpful. I have a particular project where several diverse CGI components are querying the same SQL database, with the same credentials, &c. I placed the connection info into a module called Connection.pm. All I need to do to connect from any of my scripts (or modules) is:
require Connection; die Connection::error() unless (Connection::is_up()); my $dbh = Connection::handle();
am i being retarded or bad manared separating my code into modules this way? should I only sepparate code into modules if they can be used alone ?
Modules needn't be entirely stand-alone -- many, many CPAN modules have complex dependencies, and that doesn't make them bad. If these are modules specificially useful to your project and unlikely to have broader appeal, that's ok: just release your project as one distribution rather than having a separate distribution for each module.
Modules that offer more generalized functionality are more desirable -- the point of modules is code re-use, after all. Try to think about that when you decide what you're putting into a module, but don't become over-concerned with it.
In reply to Re: how far should i split my code into modules
by radiantmatrix
in thread how far should i split my code into modules
by leocharre
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |