"NIPP, SCOTT V (SBCSI)" wrote:
> I posted the other day a question about writing a daemon to monitor
> a directory and then process the files as they arrive in said directory. I
> will begin working on this shortly, but I have a related question and this I
> think is mainly a question of good coding practice. Eventually, there will
> be several different types of files that will be hitting this directory for
> processing. The processing that occurs on each file will be based on the
> filename. I see two ways of writing this code. First, I could write each
> section of code as a separate Perl script that is called by the daemon. The
> other way I see doing this is to write each section of code as a subroutine
> within the daemon program and have that called. Any suggestions on which of
> these would be better? More correct? Etc.?
> Thanks in advance for the help yet again.
I would strongly recommend against calling other scripts. If you need to
process details as part of a problem, that is logically a subroutine, so it
seems more appropriate to use a subroutine. If the functionality of the
subroutine has larfer applicability than the current program, then the
subroutine should be in a functional module as a named subroutine.
There is at least one big practical difference between using a module and
calling another script is that a module is brought into the same processing
space as the calling code. Calling a script involves shelling out, and
interaction between the calling code and the subroutine being called is much
more difficult.
Much better to construct solid functions [aka subs], get to know the
parameter-passing rules for Perl, and then call those functions, whether they
are defined in you script or in a module.
Another advantage to susing subroutines is that, when well-named, they allow for
much more elegant communication to yourself or other humans reading. Choose
active clauses, lower case and with underscores replacing spaces, and your code
can read like a story [sort of]
Here is a very powerful function that does not in itself assign a single
variable, print anything, read anything. It delegates, and explains to the
reader/maintainer what is going on, though:
sub create_message_indices {
my $message_info = {};
my $indices = [];
load_core_header_fields($message_info, $indices);
create_Message_ID_index($message_info);
create_To_index($message_info);
create_From_index($message_info);
create_sender_date_index($message_info);
create_received_date_index($message_info);
create_References_index($message_info);
create_Subject_index($message_info);
create_skip_index($indices);
}
The program of which it is part works beautifully. In this paritcular instance,
the functions called are defined in the same file as the calling function [there
are less than ten lines of "script" in the 600-plus line file], or in a separate
module used by the script. I would recommend that you first work with calling
functions within your file, explore the use of both by-value and reference
parameters, as well as return values, and get very comfortable with calling
functions in different ways, before you move on to packaging functionality [or
class definitions, a more sophisticated use of modules] in modules.
Joseph
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]