"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]