Well, Ben offered me a ride home, so now I'm not rushing to catch a
train and can respond with content this time. :-)
> 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.
Sounds like a good plan.
> 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;
Sure -- we can add stuff as necessary.
> 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.
See what you mean, agree.
> > 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.
Yah. I'll write it within the next week, I'm pretty sure -- it's not
hard, it's something every command needs, and it'll make testing
easier. Don't worry about it for now.
> Probably because it is a baby step proposal and you are looking
> for a stride instead? :)
I think that's what was going on, yes. The step looks good, I doubt
we'd have to take any of it back. Go for it...
> 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.
:-)
I understand the proposal totally, now, sorry if I was being dense.
+1. Seems winning to me,
-Karl
Received on Sat Oct 21 14:36:14 2006