[ditz-talk] Operator Arguments
Daniel_Hackney at brown.edu
Mon Jun 16 21:03:21 EDT 2008
William Morgan <wmorgan-ditz at masanjin.net> wrote:
> > 1. Would a single patch of the whole change, rebased off of the
> > current head be best, or would a patch for each operator be
> > preferred?
> A patch for each logical set of changes, preferrably with each
> resulting in a working system. (To the extent that it's not overly
I don't know how much that would be possible, since I am rewriting how
arguments are handed to the operators, which is pretty invasive. Short
of writing a compatibility layer to allow either method of argument
parsing to be used (which I think is a waste of time), I think the best
way forward is just to squash the whole thing into a single commit and
rebase off of the current master (or edge).
> > 2. Is it still a good idea to have all of the operators in the same
> > big file, or could I break them out into one file per operation (in
> > a subdirectory most likely)?
> I'd like to keep small ones in one file, but larger ones could be
> broken out.
Since there is the "short circuit" functionality of the `--commands'
argument, it may make sense to have a small file with the information
about the commands and then all of the code separate. Then again, since
the amount of time it takes to parse some extra classes is probably
pretty minimal, worrying too much about this is probably a waste of
> > 3. Would it be okay to drop the dependency on Trollop and add
> > CmdParse [cmdparse.rubyforge.org], which is also packaged as a Gem?
> Definitely not. I wrote Trollop because cmdparse and all the other
> Ruby option parsers are clumsy and Java-esque.
I haven't found CmdParse to be that clumsy. I create a class for each
command which has an "execute" method which is called when its command
is found and passed the command line options not consumed by the
Likewise, I have been using the "optparse" library distributed with Ruby
for the parsing of the arguments. It certainly isn't perfect, but it
works and is there, and I don't feel like it is lacking crucial
functionality. I haven't taken a very close look at Trollop yet, and I
don't doubt that it is superior, but CmdParse/OptParse works and is
I think what I'll do is finish writing it with CmdParse/OptParse,
present it to you, and if you think that it is still to clumsy, I can
look at adding operator arguments to Trollop and then converting my
patch to use that.
> I actually have a reasonably simple plan for inserting operator
> arguments into ditz.
> 1. Patch trollop so that it takes a set of words which stop argument
> processing at that point.
Alternatively, CmdParse has the option to wrap around an existing
argument parser. We could write a wrapper for Trollop and use the
command-parsing ability of CmdParse without too much trouble.
> 2. In ditz, give trollop the set of commands as that set of words.
> 3. For each command that takes arguments, re-invoke trollop with the
> set of command-specific arguments.
Sounds good. That's basically what I am doing now, only with the
> > One of my goals is to be able to create a "batch mode" [...]
> I'd love to have this too. Most of the user input (besides asking for
> comments) is actually invoked programmatically by
> ModelObject.create_interactively, so having e.g. a set of commandline
> arguments that specify the needed text is fairly straight-forward.
>From what I could tell, all you really need to do is to pass enough
stuff in the ":with" hash option to keep it from asking anything. It
might be nice to have some list of the options each operator needs in
order to run in batch mode and fail if they are not met.
For example, many commands take a comment message, but they can either
take a string on the command line, a filename to read from, or the "no
comment" option. It would need only one, since each of them satisfy the
That could come in a separate patch, though.
Daniel M. Hackney
Providence, RI, 02912
Cell: (610) 368-7607
More information about the ditz-talk