in reply to Distribution of Program and/or Module

Module on CPAN. There's several benefits:
  1. I might want to do things your script doesn't do, but I want to reuse your code. Maybe, I want to implement IEBPTPCH on A, but fail-over to B if A can't be gotten. Easy to do if your code is a module, but not so easy if it's a script. Or, I might want to do DBI commands while I use your module.
  2. I might want to implement other IBM Mainframe commands.
  3. I might want to use your API to talk to a CRAY instead of an IBM mainframe.
  4. Having a module allows it to be easily integrated into a persistent environment, such as mod_perl.
Scripts don't have the flexibility modules do.

Now, this isn't to say you shouldn't distribute your script as part of your CPAN distribution. There is a place for scripts and it would be an excellent example of how you have used this module.

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

  • Comment on Re: Distribution of Program and/or Module

Replies are listed 'Best First'.
Re^2: Distribution of Program and/or Module
by Tanktalus (Canon) on Mar 10, 2005 at 15:42 UTC

    Let me expand on this just a wee bit.

    One of the developers reporting to me wrote a very useful script that we needed. However, he wrote it as a script rather than as a module. What that meant is that I could not embed it into the overall perl project that we are using - well, not easily. I rejected his implementation (would not sign off on it) based solely on this aspect. He is converting it into a module right now.

    Yes, it's that important.

    He will also create a sample script that all it does is convert the command line parameters into arguments for calling the function in the module. So the external behaviour will be unchanged, but the internal behaviour will allow us a lot more flexibility. We're going to be using the code in ways I'm sure he hasn't imagined (because if he had imagined, the code would have been a module in the first place). These other things include things such as reading the parameters from an XML-like datastore, or reading lists of files from the filesystem. The latter is one he thought of, the former is not.

    Thus, I'd suggest creating a tarball that included the module with all the functionality, and a wrapper script that allows you access to that functionality from the commandline. It would also serve as an example for those who wanted to write their own scripts to do other things, or to get input from various locations.