leocharre has asked for the wisdom of the Perl Monks concerning the following question:

I am putting this app together, an online document access management system. I want to be able to install it on diff machines, I want to release parts of it and eventually the whole thing on CPAN. It's a big project, and the code is getting bigger. My running script is very small, it just calls some functions from included modules, like &get_tainted_data, &check_tainted_data, &get_session_data, &print_html_header .. etc etc.

subs that deal with simply html stuff are in a module like Html.pm, stuff that deals with file info, file actions, etc is in Files.pm, stuff that deals with sessioning is in Session.pm etc etc..
All this has really helped me move along, isolate development bugs, etc

I want to conform to the community's standards- Just what should a perl module do? As it stands my modules pretty much depend on each other- so... 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 ? Am I worrying too much about this, should I just go apesh&t and make any modules I want and .. even.. pl files and the old function files.. what were they, pf or something.. ?

I've read some texts on modules. there's a lot of talk about syntax, structure, scope, etc .. but where can i find some.. about.. ethics? and making it more useful to other people?

update: I have simplified my question: If I have cake.pm and dog.pm, and neither does anything useful without the other.. should they not be dogcake.pm instead ?

  • Comment on how far should i split my code into modules

Replies are listed 'Best First'.
Re: how far should i split my code into modules
by radiantmatrix (Parson) on Feb 02, 2006 at 21:11 UTC

    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.

    <-radiant.matrix->
    A collection of thoughts and links from the minds of geeks
    The Code that can be seen is not the true Code
    I haven't found a problem yet that can't be solved by a well-placed trebuchet
Re: how far should i split my code into modules
by holli (Abbot) on Feb 02, 2006 at 20:50 UTC
    The way you do it, breaking functional parts into modules, is just fine. Just make sure you put your modules into a separate namespace, so your module "Files" becomes "YourProject::Files".


    holli, /regexed monk/
      yes, i am doing that. that's not a problem. i have my WebAPP.pm then my Webapp/Flush.pm Webapp/Toilet.pm etc , and the module package names are properly named Webapp::BrushTeeth etc .
Re: how far should i split my code into modules
by Fletch (Bishop) on Feb 02, 2006 at 21:28 UTC

    Sage advice from Herr Einstein:

    Everything should be made as simple as possible, but not simpler.

    Perhaps more directly germane, I think Perl Best Practices has a chapter (or two) that might address this (although I've yet to read it yet, the TOC says chapters 16 and 17 look promising).