From: Greg London <[EMAIL PROTECTED]>
Date: Thu, 09 Sep 2004 09:43:38 -0400
. . .
A quick email to Damian with your rule search/replace/rename
question might get you a quick answer. who knows, Damian
might be able to tweak it while he's on a long flight somewhere.
If you figure something out, lemme know.
I could probably use it too.
Remember that I already have a pile of code that plays nicely with
Getopt::Long, so converting to Getopt::Declare at this stage is not
terribly appealing . . .
From: Greg London <[EMAIL PROTECTED]>
Date: Thu, 09 Sep 2004 10:47:45 -0400
Greg London wrote:
>
> Bob Rogers wrote:
> > 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.
Hey, just a random thought, but rather than building up a simple
string in a global variable, could you build up a global hash?
. . . Then, your main script would use SmartArgs to get the command line
parsing working, and all the other modules would use the global hash
in SmartArgs to declare/delete/rename/change the arguments.
Hm, might have to put that on my to-do list.
This is a decent idea, but not without problems. In fact, I mentioned a
few of them when I suggested it yesterday. ;-}
Seriously, splitting up the options this way does make it easier to
combine them, but it still requires globals to store the values, and as
long as that's true, I find it hard to imagine a solution that can deal
cleanly with options for multiple instances of the same class.
But this morning, I had an idea for Pod::CLOD while showering.
(That's a good sign; some of my best ideas come to me in the shower.)
If the command_line_options method returns the delegated objects so that
Pod::CLOD can query them directly, that would not only give Pod::CLOD
complete information on how the option list is built, it might also make
it easier to use.
In particular, string constants are useless to GetOptions as places
to put option values, so I could use something like
'foo-option' => -omit
at some point in the list constructed by a command_line_options method
to tell it that the program shouldn't handle '--foo-option' at all.
Also, providing
'foo-option' => -override
would also be useful as a way of telling it drop '--foo-option' if it is
currently defined, so that the next occurrence (if any) would be used.
That is probably the only way for ModuleC to select --foo from ModuleA
and --bar from ModuleB if both modules define both options. (But I know
somebody will take it upon themselves to prove me wrong in short order.
Uri? ;-)
I could then handle delegation with a special option name:
-delegate => $delegated_object
and the Pod::CLOD option processing would know to ask $delegated_object
for its command_line_options list. The -delegate keyword shouldn't
interfere with anything GetOptions would accept, and could be repeated,
causing the delegate's list to be processed at the point it was
encountered.
This should give each command_line_options method full control over
how its options are constructed, while allowing Pod::CLOD to do all the
hairy parts. It also means that I would know exactly which classes
contributed which options, which should make it easier to get the right
option documentation strings.
If I have time, I'll work on implementing this over the weekend.
I'll send email when I have something working (though this time I'll
probably put the source on my Web site rather than posting it.)
Thanks for letting me bend your ears,
-- Bob
_______________________________________________
Boston-pm mailing list
[EMAIL PROTECTED]
http://mail.pm.org/mailman/listinfo/boston-pm
