How best to oganize this perl code

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

So I am writing some perl scripts that are being compiled to windows executables. Some of the perl scripts implement some basic functionality required by some of the other perl scripts. Furthermore, these scripts with the basic functionality need to be able to be called from the command line as well as by other scripts.

My question is would the best and maybe only way to do this be to call the executables with the required functionality from the perl scripts? Basically I have scripts a.pl and b.pl which will be given to users as a.exe and b.exe. b.pl needs to be able to run from the command line and called from a.pl. Should I simply make a call to _b.exe_ in a.pl or is there a better way to organize this?

I was looking at modules, etc. but I'm not sure if it is ideal in this case since the users will have both a.exe and b.exe on their machines. It would seem that this would just lead to a bigger executable for a.pl and not achieve much for me.

Comment on How best to oganize this perl code

Replies are listed 'Best First'.
Re: How best to oganize this perl code by ikegami (Patriarch) on Sep 08, 2004 at 21:28 UTC
The best question to ask when contemplating optimization is "How often is this called?" If a doesn't call b often -- once an hour is not often -- then there's probably no reason to include b in a. Another question to ask would be "How does this affect the user?" If a is an interactive program, and the user must wait for b to launch, it might improve the user experience to include a into b. If a is not interactive, b could still affect the user if it uses an excessive amount of CPU or IO at startup.	[reply]
Re: How best to oganize this perl code by castaway (Parson) on Sep 09, 2004 at 05:35 UTC
This depends on what actual code is in b.pl, and what a.pl needs it for. Does a.pl just call it because it performs some function that a would otherwise have to duplicate, or does it also need b to do some user interaction? IE. Can you abstract what b does into a module, that both could call? If so, do that. If b is a standalone exe that a just happens to need, then call the exe, if that is what you are delivering. C.	[reply]
Re^2: How best to oganize this perl code by richz (Beadle) on Sep 09, 2004 at 13:19 UTC
C, Your idea is what I ended up deciding on. Like you figured, I did not want to duplicate the function that b.pl was providing in a.pl. I decided on making b.pl a module for this reason; the downside since I am compiling these into executables is that if I enhance or modify b.pl I will have to compile a.pl into a.exe again... Thanks.	[reply]
Re: How best to oganize this perl code by Anonymous Monk on Sep 09, 2004 at 10:30 UTC
Unix approach: have lots of different, small, programs that each do one task well. MS approach: have huge programs each one having everything and three kitchen sinks.	[reply]