>>>>> "BR" == Bob Rogers <[EMAIL PROTECTED]> writes:
BR> But this morning, I had an idea for Pod::CLOD while showering.
BR> (That's a good sign; some of my best ideas come to me in the shower.)
so you aren't a filthy bastard then? :)
BR> at some point in the list constructed by a command_line_options method
BR> to tell it that the program shouldn't handle '--foo-option' at all.
BR> Also, providing
BR> 'foo-option' => -override
BR> would also be useful as a way of telling it drop '--foo-option' if it is
BR> currently defined, so that the next occurrence (if any) would be used.
BR> That is probably the only way for ModuleC to select --foo from ModuleA
BR> and --bar from ModuleB if both modules define both options. (But I know
BR> somebody will take it upon themselves to prove me wrong in short order.
BR> Uri? ;-)
it makes more sense. but i will offer something very interesting (IMO :)
and very old but it might be more like what you want. when i first
shifted from perl4 to 5 i wrote an arg parser using refs and such as an
exercise as well as to claim that i also wrote another arg parser. i
never cpan'ed it as i would want to do a full rewrite of parts (make it
more OO and clean up stuff). its advantage to you is that it is driven
by a list of hashes that describe each option. you could then do
something like have each module just have an inherited class method call
that returns its list of arg descriptions. these methods will also call
their SUPER::method to get the inherited methods and merges those arg
descriptions with its own. the top level makes the first call this this
method and then it takes the inherited and merged arg description list
and uses that to process argv. you can implement some way for the main
script or modules to handle which options come from which module. adding
arg attributes could be used in this way (similar to the --override
thing). the merging code would look at those attributes and decide
whether to use the merged arg description or the new one coming in from
an inherited module.
BR> I could then handle delegation with a special option name:
BR> -delegate => $delegated_object
BR> and the Pod::CLOD option processing would know to ask
BR> $delegated_object for its command_line_options list. The
BR> -delegate keyword shouldn't interfere with anything GetOptions
BR> would accept, and could be repeated, causing the delegate's list
BR> to be processed at the point it was encountered.
this sounds like an include mechanism for arg descriptions.
BR> This should give each command_line_options method full control
BR> over how its options are constructed, while allowing Pod::CLOD to
BR> do all the hairy parts. It also means that I would know exactly
BR> which classes contributed which options, which should make it
BR> easier to get the right option documentation strings.
i think that is pretty much what i just described but with a different
way to do the work.
you can find this 7 year old (but amusing) argv parser here:
http://sysarch.com/perl/Argv.pl
i can see many ways to improve and shred the code. i would me just as
mean to myself as i am to others! :) so go ahead shred away if you
want. i think the concept and design of this code has merit but as i
said before it needs cleaning up. damian's thing does all the same
things but uses parse::recdescent which can be slower (but i haven't
benchmarked them). this does have some interesting features like
mutually exclusive options, option validation, flexible ways to store
option values (needs a single hash for all options feature). and there
are many perl4isms to be ripped out like &sub calls, too early my
declarations, etc. as i said, it was an exercise and learning perl5
experience. have the appropriate amount of fun!
uri
--
Uri Guttman ------ [EMAIL PROTECTED] -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
_______________________________________________
Boston-pm mailing list
[EMAIL PROTECTED]
http://mail.pm.org/mailman/listinfo/boston-pm
