|
Boost : |
From: David A. Greene (greened_at_[hidden])
Date: 2001-11-20 10:35:55
Petr Ovchenkov wrote:
> Hmm, while you mixed walk through catalog and argument parsing?
> IMO it a different tasks.
Who are you responding to? I'll assume it was me. While
it's true that my current implementation mixes the
two, it does not have to be that way. The programmer could
create an ordering spec, pass it to the parser. The parser
parses the cmdline, saves state for all the arguments it
has seen and then applies the ordering to invoke the
actions in the correct order. I'm thinking way off the
top of my head here so don't tear me down too badly. :)
But I think we're getting away from the main point I
was trying to convey -- there are some capabilities I
use in my option processor that I hadn't seen mentioned
here:
- Sub-options/option trees/nested options
- Action objects
The second is of course an implementation detail -- the two
points are orthogonal. I have found the second to be a
useful design encouraging separation of code for declaring
options and code for acting upon them, with no need to
manually check whether an option was given. Why should
the programmer have to declare an option and then write
code to check if it's there? By declaring the option
the programmer is conveying that, "hey, this is something
interesting and I want to do something when it appears."
I simply presented my current design as proof that it
is feasible and commented that I've found it to be
very flexible and useful. I don't expect to submit it
to Boost because others have far more experience dealing
with many option string formats, etc.
-Dave
-- "Some little people have music in them, but Fats, he was all music, and you know how big he was." -- James P. Johnson
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk