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

Esteemed Monken,

I come asking for your wisdom, as Super Search has failed me (or maybe I failed it?). Context, this is work-related.

We have a bunch of scripts that create reports from our database, reports of various shapes and sizes. But the more we work on these scripts (generation, we call them), we can't help but realize they all start out very similarly (strict, warnings, GetOpt, option processing...). Some reports ask for params A, B, C, others ask for A, B, D, and yet others ask for A, D, E (and so on).

We were wondering if anyone had any experience with (or could point us to an existing thread/resource/discussion about) modularizing scripts that are similar, yet still different enough.

We already have a set of specialized modules that handles all of the DB and utility/validation stuff, so would this be another one of those in-house modules? NameSpace::Report?

Many thanks, and much Perl.

-deep

PS - Apologies if I wasn't clear enough. Also, please feel free to change the title, I don't know how to make it any more explanatory/searchable...

  • Comment on Generalizing Similar Scripts into a Module

Replies are listed 'Best First'.
Re: Generalizing Similar Scripts into a Module
by rafl (Friar) on Mar 16, 2006 at 23:32 UTC

    Hello,

    Of course providing a simple recipe for that, that'll work in every case is quite impossible. I also don't know enough about your specific application to be able to say what I would really do in your case. Nevertheless I'll try to explain what my general approach to such problems would be.

    • Find out what/where the similarities of the scripts are
    • Way 1
      • Put all the common code (performing database queries, commandline parsing) into a module which implements a class
      • Write other classes that inherit from the above base class and implement the specific behaviour of the current scripts in them
      • Now you have classes that implement all work and that inherit all common stuff from the base class. No you only need to write some small scripts that simply make an instance of one of the child classes and actually call the code that does the work.
    • Way 2
      • Parameterize all problems in a way that one piece of code can theoretically perform all the work the different scripts, when it recieves the according parameters
      • Write replacements for the current scripts that are just a thin wrapper about the parameterized code above

    That would be two ways to solve that problem that just came to my mind. There may be a lot of other ways, that also may be better in your specific case. I just can't know..

    Cheers, Flo

[reply]
Re: Generalizing Similar Scripts into a Module
by zer (Deacon) on Mar 16, 2006 at 23:33 UTC
[reply]
Re: Generalizing Similar Scripts into a Module
by bowei_99 (Friar) on Mar 17, 2006 at 07:53 UTC
    I think rafl's reasoning for suggesting OO was that the general operations were similar, but there were slight variations, depending on the situation. That's a situation where PBP says using OO would be appropriate.

    However, TheDamian also says to make OO a choice, not default. In a nutshell (my paraphrasing of pp. 320-321), if you have

    • a large-scale, enterprise-type environment
    • that changes often and
    • where programmers are using OO
    or your data
    • is hierarchical,
    • requires operations that are similar one another

    it may benefit you to use OO. Oh, there were a couple situations in the book I left out, but that should give you the gist of it.


    Also, I'd highly suggest using Perl6::Export::Attrs in writing your modules. I could never remember the syntax for writing a module, and it was a major reason why I hadn't gotten around to refactoring my code into modules, until recently. But with this, it's a lot simpler - you just specify the module with a 'use' statement, and specify :Export in your subroutine if you want it exported from the module. Example:

    package myModule;

use Perl6::Export::Attrs;

sub DoSomething :Export {
      #whatever 
}

    [download]
    Of course, you can specify more, but you can look at the docs for that. This code should get you started. Oh, and you don't need to install Perl6 itself to get this, by the way; I've been using it fine on 5.8.7 and 5.6.

    -- Burvil

[reply]
[d/l]
Re: Generalizing Similar Scripts into a Module
by planetscape (Chancellor) on Mar 17, 2006 at 18:00 UTC
[reply]

Back to Seekers of Perl Wisdom