http://qs1969.pair.com?node_id=249591

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

Fellow Perl Monks,

I have been writing Perl scripts for approximately 2 years now, but, I have never found a reason to create a module or package. Yesterday I had some extra time so I spent it creating a module to perform a file naming subroutine that I use in most every Perl script that I write.

My question is: How many times in general do you reuse a subroutine or piece of code before you turn it into a module or package, or are packages and modules not that widely used?

Thanks in Advance,

Greg

Replies are listed 'Best First'.
Re: Perl Module Useage
by Improv (Pilgrim) on Apr 10, 2003 at 12:52 UTC
    Practice differs in this area, but I would suggest the following guidelines:
    • If you use it all over the place, it should probably be in a package or some other shared place so if you enchance or bugfix it one place, you don't need to hunt down all other copies
    • If you want to share it, it's easier for people to take your code as a package/module than to cut'n'paste it, and it makes version tracking easier
    • Of course, if you're doing objects, it's best to put them into packages :)
    In short, packages/modules are usually a good thing, provided the borders between them are sensible, and provided you have time to structure your code that way. It doesn't hurt if you start new coding projects programming entirely in that fashion. That way, you'll develop nice templates and tools to help you, and once you get used to it, any moderately big application (or set of small ones) will be just as quick to implement that way as the flat way.
Re: Perl Module Useage
by shotgunefx (Parson) on Apr 10, 2003 at 12:47 UTC
    It depends. There are other reasons to abstract. If many of your scripts that use that code and you find a problem in that code, it much easier to update the module then patch a bunch of scripts.

    For instance all of our apps that send mail and admin alerts import them from a module. (We use our own mail function instead of directly using a module as were it ends up may vary MTA wise) so it's a snap to update the config when moving between machines. Another good example was I'm about to walk out the door and an automated system we exchange data with ran amok one day (It sends info to us and we notify customers). I simply added a DB_File and MD5 hash of the message (too supress duplicates) and easily stopped our customers from getting bombed with email and the best part is that it only took 5 minutes and I was on my way out the door.

    -Lee

    "To be civilized is to deny one's nature."
Re: Perl Module Useage
by bronto (Priest) on Apr 10, 2003 at 12:45 UTC

    The 95% of the times, I decide to create a module for a task before I actually write any piece of code. Another 4% of the times is when I face a task that I remember I already solved and I do some cut-&-paste-&-glue to create a module from the existing code.

    ...and the other 1%? It's when I save a quick&dirty script for using it again once or two times a year :-)

    Ciao!
    --bronto


    The very nature of Perl to be like natural language--inconsistant and full of dwim and special cases--makes it impossible to know it all without simply memorizing the documentation (which is not complete or totally correct anyway).
    --John M. Dlugosz
Re: Perl Module Useage
by cbro (Pilgrim) on Apr 10, 2003 at 13:00 UTC
    The reason you, "have never found a reason to create a module or package", may just be due to your programming style. If you're used to procedural programming, abstraction may not seem like the right choice. You're probably used to creating subroutines...it's just that you don't pull them outside of your scripts. I like shotgunefx's comment, "If many of your scripts that use that code and you find a problem in that code, it much easier to update the module then patch a bunch of scripts."
    If you are going to reuse your code even once, you may want to consider making a module out of it. Why recreate it...again, even once.
      I learned that the hard way. I started in C and ASM in the late 80s. Self taught and I didn't know any better about cut and paste. I came to realize that almost every time I cut and past duplicate logic that I would later find a problem and have to fix it everywhere. A much larger problem when it's was huge ASM program and no Perl to grok it for you. :(

      -Lee

      "To be civilized is to deny one's nature."
Re: Perl Module Useage
by Biker (Priest) on Apr 10, 2003 at 13:43 UTC

    I typically think in objects when I develop my systems. As a result, I spend more than 99% of my time creating classes from where I instantiate objects.

    I do have a similar problem as yours, since I constantly ask myself when I should bring out a class from my application source file and make it a separate module file.

    When I write a new class for the first time, I try to think if I can make it generic so that it could be reused by a future application and more often than just often this is the case.

    If I don't immediately see the usage for the class in another application, I tend to keep the class in the original application's source file. At the first occurence of reuse, I have a very small effort to cut out the class and put it in it's own module file.

    There is a small disadvantage with a module file; Distribution and installation. Especially to remote systems and when you have different systems for development, integration test and production. (Which is my case.)

    On the other hand, if the class/module can be reused in more than one application, the reuse related advantages almost immediately outweights the distribution and logistics costs/efforts.


    Everything went worng, just as foreseen.

Re: Perl Module Useage
by dga (Hermit) on Apr 10, 2003 at 16:12 UTC

    I have 2 general rules of thumb.

    First: If I need to use a bit of code in more than 1 place, I take that time, instead of a cut/paste, to make it into a sub and change the existing bit of code to call the sub and the new bit of code becomes a call to the same sub.

    There are times when the sub needs to be made a bit more generalized and I handle this at that time also.

    Second: If I want to use that sub in another script I build that sub into a module which I can then import the function.

    At the same time, if it makes sense I try to make the sub into an OO type of interface so I don't need to import the functions into my scripts unless it really makes sense to do it that way.

    My experience is that if this overhead is done when there is only 1 existing piece of code which requires changing to use the new interface (sub {} or use Module;) then it is quick and easy to have these nice interfaces so that next time I want this functionality I just type use Module; my $thing=Module->new(...);, or use Module qw( my_keen_sub );

    This has a really low cost in the short term and a huge win in the medium to long term, especially if I add a bit of pod to the sub and then a bit more when it gets into a module.

Re: Perl Module Useage
by bart (Canon) on Apr 10, 2003 at 22:59 UTC
    My mind doesn't work that way. In general, if I need a piece of code more than once in a script, or might so, I turn it into a sub. If while doing that I get the feeling I'm solving a generic problem, not one specifically aimed at the specific problem the script it's trying to solve, I turn it into a module. That is, even before I ever used it, even just once. Why shouldn't I. It's not that much extra work.
Re: Perl Module Useage
by gawatkins (Monsignor) on Apr 11, 2003 at 11:40 UTC

    I would like to thank everyone for their speedy input on my question. I am employed as a Systems Admin, so most of my Perl usage is dedicated to reading and manipulating various log and config files. Since most of my scrips are very similar, I think that modules are the way for me to go.

    Thanks Again,

    Greg

Re: Perl Module Useage
by P0w3rK!d (Pilgrim) on Apr 11, 2003 at 15:50 UTC
    Greg,

    It depends on many things. In general, you should try to make your code modular and reusable as much as possible. You never know when or where you'll be able to use your code again. -Especially with constantly changing business requirements. If you use the same function elsewhere and just cut-and-paste, then you create the problem of having to update n number of copies of the same sub.

    -P0w3rK!d