My proposal is to *not* do anything significant. :-)
Instead, it is merely to isolate it so that experimentation
becomes easy. Then, I will experiment a little bit and
come up with a proposal. Whatever proposal would be something
that specified the acceptable/required options to an
option processing engine that would be driven by that
something, rather than command name. The resulting state
would get handed back to the implementation procedures in
any of a myriad of ways.
For the time being, this is far and away the most trivial
to implement and use for an experimental framework:
typedef struct svn_cl__opt_state_t {
svn_string_t *xml_file;
svn_string_t *target;
svn_string_t *ancestor_path;
svn_boolean_t force;
svn_cl__command cmd;
const char *use_text;
} svn_cl__opt_state_t;
a pointer to this struct gets added to the command descriptor.
The option processing routine takes this ptr as an argument, instead
of the addresses of each of the fields. It is trivial and gets me
closer to where I want to go, even if the destination still has haze.
> 3. Remaining arguments are files and dirs. Have a single function
> that removes redundancies from this set (if you're recursing
> into bar anyway, then mentioning bar/foo.c is pointless), and
> passes it along to the command as the keys in a hash table.
cute idea. Certainly not today, tho.
> Greg Stein <gstein@lyra.org> writes:
> > I'd suggest passing the options information to the command in
> > a hash table. The command can simply do something like
> > apr_hash_get(hash, "v") to get the information.
> > Throw in a bit of default value handling, long/short option
> > handling, and you're set.
Yeah, easy. It's only software. But too ambitious for tonight.
> > The second part would be determining what is possible for a given command
> > and providing errors/warnings for options that don't match up properly.
Right now, I'll do that just with the command code enumeration.
The real implementation will do something better.
> > On Tue, Nov 14, 2000 at 03:45:43PM -0600, Karl Fogel wrote:
> > > Actually (I apologize if I'm just being dense, here) I'm not sure I
> > > understand the proposal completely..
Probably because it is a baby step proposal and you are looking
for a stride instead? :)
> > > I like the idea that only main() has to parse the options, and then
> > > passes along the information postparsed to the subcommand, especially
> > > given that so many options have a common meaning across subcommands.
> > >
> > > However, I don't understand the mechanism by which this is happening;
> > > specifically, the mechanism by which main() passes the information
> > > along. It sounds like it's at least partially genericized,
Not a bit of that. The code will be essentially unchanged, except
the main() routine will have access to the command code enumeration
and will pass it to the arg processing routine, instead of the
separate command procedures. This is a _very_ tiny step.
> > > How are those [data] passed? Are we going to make the
> > > subcommand procedure type variadic?
One big struct.
> > > As an experiment, could you try writing the log entry in advance and
> > > posting it?
Humm. This was *supposed* to be a first approximation:
> > > > In preparation for ultimately doing some sort of
> > > > table thingey for options, I want to lay some ground work
> > > > now. To do this, I want to make a struct type that
> > > > contains all the data currently used in the client
> > > > options, plus the command enumeration type. Each
> > > > command table entry would have a pointer to a struct
> > > > of this type with just the command enumeration filled
> > > > in. The current option processing code would be called
> > > > from main() instead of the command procedures. The command
> > > > procedures would receive only command arguments (the
> > > > options stripped off). With this done, changing the
> > > > underlying option processing should no longer perterb
> > > > much of any other code (especially the command implementation
> > > > procedures.)
static svn_cl__cmd_desc_t cmd_table[] = {
/* add */
{ "add", NULL, svn_cl__add, &add_cmd_opt_state },
{ "ad", "add", svn_cl__add, &add_cmd_opt_state },
{ "new", "add", svn_cl__add, &add_cmd_opt_state },
.....[etc.]
Received on Sat Oct 21 14:36:14 2006