in reply to Multiple GetOptions?

Personally, i see a design problem here ... but i don't know exactly what you are building, either. ;)

Generally speaking, i think that a module should have an interface that is not dependent on something like Getopt::Long. I feel that Option modules are better fitted with CLI (command line interface) scripts. What if you wanted to used the module from a CGI script or mod_perl -- AKA, a Web interface? If so, then your module should not be pulling arguments from STDIN, instead the client should read from STDIN (or the socket) and simply pass the data as method arguments to the module. It's not really that much more work, but the flexibility outweighs the extra typing, IMHO.

UPDATE:
Sounds valid and interesting. Please let me know how it goes. :)

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

Replies are listed 'Best First'.
Re: Re: Multiple GetOptions?
by PetaMem (Priest) on Feb 15, 2004 at 17:33 UTC
    The module shall provide explicitedly a "scripting environment". There's a bunch of scripts for natural language processing (esp. statistical NLP) we're using.

    Many of these scripts are standalone, but there is much redundancy. This is a try to provide a "general scripting environment infrastructure" for common tasks and processes of these scripts.

    Bye
     PetaMem
        All Perl:   MT, NLP, NLU