From: "Greg London" <[EMAIL PROTECTED]>
Date: Wed, 8 Sep 2004 11:47:50 -0400 (EDT)
Bob Rogers said:
> easier to add command-line options through class inheritance and reuse
> than it is to document them. I have attached an early version of the
Hm, I've been using Getopt::Declare for a lot of
command-line scripts at work. I'm not a webhead,
I do command line tools, so command line options
is my bread and butter.
Getopt::Declare lets you document and design your
command line arguments in one simple text string . . .
Excellent; thanks for pointing this out.
. . .
You might be able to have a BEGIN block in every module
that concatenates their specific string to some agreed-upon
variable, and then when you "use" a module and all of its
base classes, you will end up with a string somewhere that
should be usable by Getopt::Declare and should also act
as your documentation/help.
I think I'm already well past that point in terms of option-parsing
complexity. I have places where the command_line_options method calls
SUPER::command_line_options in order to replace/rename options, so I
need some way to supercede and/or rename things. For example:
package MyModule;
BEGIN
{
$main::Getopt_Declare_Hash{in} = <<'INTERFACE';
-in <filename> Specify an input file
{ $main::in = $filename; }
INTERFACE
}
. . .
Then other modules could substitute their own '-in' parser, though that
would make the order of loading critical. And finally pass
join('', values(%main::Getopt_Declare_Hash))
to Getopt::Declare. (Which spoils "[ditto]", though.)
It also strikes me as messy to use globals to store option values
that will eventually be stuffed into object slots. One could use
{ $main::obj->input_filename($filename); }
to do the deed directly, but that just replaces one global with another.
The module is effectively telling its caller what to name the variable
in which it must live.
This is not just an esthetic problem, either; I have a case where a
class delegates to two instances of the same module
(ModGen::ObjectStreams::PCRFactory in fact, about which more in a
subsequent message), because I generate two sets of PCR oligos for
different purposes, requiring independent parameters. Currently I do
something like
sub command_line_options {
my $self = shift;
($self->pcr_targets->make_prefix_option_setters('pcr'),
$self->pcr_factory->make_prefix_option_setters('asm-pcr'),
. . .);
}
(The real code is uglier than that, so I'm still not happy with it, but
I'll spare you the gory details.) Each make_prefix_option_setters call
returns the same options with the specified prefix that alter $self,
which is what makes it work. I don't see an easy way to use
Getopt::Declare to do anything similar; do you?
Thanks again; even though it looks like Getopt::Declare won't help me
directly, I do appreciate learning about it.
-- Bob
_______________________________________________
Boston-pm mailing list
[EMAIL PROTECTED]
http://mail.pm.org/mailman/listinfo/boston-pm
