commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Oxspring" <>
Subject [CLI] Do we have the correct model? (was Re: [CLI] Support for CVS style command line)
Date Tue, 17 Jun 2003 13:24:04 GMT
I've had a little look into implementing Commands as I described but wasn't sure how I'd get
them in without adding spaghetti to the
code.  While looking around I was reminded of a few things that feel slightly wrong and began
to wonder whether the model might be
wrong.  I'll outline the problems and then a solution below that seems pretty clean to me.
 The pure text UML could be prettier but
I think you'll get the idea if you use a fixed size font. (I hope you don't regret the "bouncing
the ideas around" comment too much
John :o) )

OptionImpl vs. CommandImpl.  Although these two types of object share the common feature of
appearing on a command line and having a
group of child options, I'm not convinced that one is an extension of the other.  As a result
I've struggled to fit Command into the

Option vs. Argument.  It might be just me but in the command "ant -f file" I've always regarded
it as an option -f with an argument
file, whereas the current model would have an argument "-f file".  This has caused me occasional
confusion and it seems that it
would sit easier if Argument were able to deal purely with the "file" section and not have
to deal with the option's properties.  If
the Argument were able to drop the option properties then it might also be possible to mix
Arguments and Commands together.

AnonymousArgument and UnsupportedMethodException.  Again it might be a personal thing but
I've always thought of UME as being a bit
of a code smell - to me it says "the object isn't really a subtype of the specifying class
but we've put it here anyway, so there".
I think this strengthens the case against Argument implementing Option.

CommandLineParser knows an awful lot.  I've commented before that the internal handling of
-D and -- should be optional but the
knowledge of how all the other options behave seems to be encoded in this class too.  There's
nothing inherently wrong with that but
it left me thinking it odd that the Option implementations didn't control the behaviour themselves.
 It also struck me that the same
would be true of any HelpFormatter built for the current model.

Without boring you with the route my thoughts took, here's the model I came to with a bit
of explanation afterwards.

Class Diagram (Inheritance):

Option <-----------+-- Options <---------------+-- ExclusiveOptions
  getDescription() |     parse(...)            |
  isRequired()     |                           +-- InclusiveOptions
  appendUsage(...) |
  validate(...)    +-- ParentOption <----------+-- DefaultOption
  process(...)     |     processParent(...)    |
  canProcess(...)  |     processChildren(...)  +-- CommandOption
  getPrefixes()    |
                   +-- Argument
                   +-- PropertyOption
                   |     getInstance()
                   +-- IgnoreOption

Class Diagram (Composition):

Argument --------1 ParentOption --------1 Options --------* Option

The first thing to note is that I've separated out the Option interface from the DefaultOption
class.  The Option interface has lost
most of its structure enforcing role and gained behaviour specifying instead.  Some new OptionBuilder
would build DefaultOption
instances with all the longName / shortName and other properties of the current OptionImpl
class.  Similarly a CommandBuilder would
allow CommandOption instances to be built up with preferredName / aliases properties.

Another important point is that Argument is no longer directly related to the DefaultOption.
 Instead it is composed of either a
DefaultOption or CommandOption and concentrates purely on the details of the argument.

Options just becomes a generic object for storing a set of options, the Exclusive / Inclusive
just specify more restrictive
behaviour as they do presently.

The idea of PropertyOption (-D) and IgnoreOption (--) just dropped out of the structure and
means that this standard behaviour can
be treated as any other option and if people have their own plan for a -D option then they
simply don't put a PropertyOption
instance in their Options.

After a little experimentation the sensible methods for Option to specify seem to be the following:
getDescription() - used to allow a HelpFormatter to describe any given Option.
appendUsage(...) - allow the option itself to append a usage string to a StringBuffer
validate(...) - validates a CommandLine's use of this Option
isRequired() - presumably used by validate() and appendUsage()
process(...) - takes a ListIterator of arguments and deals with some/all of them.
canProcess(...) - checks that a call to process(...) will succeed.
getPrefixes() - returns the argument prefixes that could indicate this Option can process
a given argument.

One of the nice things about this structure is that when somebody wants to extend the system
to cope with windows style "/?"
options, or case insensitive commands, they should only need to add a single Option implementation
and any Parser and Formatter will
automatically cope.

I've not yet figured out whether a separate AnonymousArgument is needed or if an Argument
could exist without a ParentOption but I'm
sure that the UnsupportedMethodException methods would be gone completely whichever route
was taken.

So, thoughts? I'm happy to answer questions and help with implementation as time permits but
I'll be on holiday from Friday for 10
days so will be offline for a while.


----- Original Message ----- 
From: "John Keyes" <>
To: "Jakarta Commons Developers List" <>
Sent: Thursday, June 12, 2003 10:18 AM
Subject: Re: [CLI] Support for CVS style command line

> > The "setDisplayCommandAlias(boolean)" is purely hypothetical at the moment, it illustrates
> > the level of control I was planning on offering but is beyond the implementation
so far.
> > I haven't tackled Commands and aliases at all but I guess should put my code
> > where my mouth is.  I'll keep you posted on progress.
> Keep bouncing the ideas around anyway.  If you don't get around to implementing it
> at least the knowledge will be archived.
> Thanks,
> -John K
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message