Fwd: [CLI] Suggestions

[Martin Redington <m....@ucl.ac.uk>]

I've just been writing my own Command Line Parsing library, when duh! I 
looked to see what was out there, and came across commons-cli.

Its quite interesting to see the similarities between my implementation 
and commons-cli

I have an "Options" type class as my main entry point, and posix 
support (my library is built on top of the gnu-getopt package), 
automatic generation of usage statements, command line parsing, and and 
a similar usage pattern of create/parse/query.

Generally, the CLI implementation is neater and tidier.

However, my class has a number of features that CLI doesn't seem to 
have (after a browse through the archives, I found that some of these 
were anticipated by David below). Some of these might be there in CLI, 
but I didn't see them after a brief perusal of the docs ...


1. Options are typed (boolean, string, integer, double), with the type 
being determined by the type of a default value that is passed in 
during construction. This means that there are a *lot* of constructors, 
as everything is heavily overloaded. From the user (developer) 
perspective, if you pass the right kind of object in as a default, then 
the library will do all the work (including checking the values 
supplied on the command line). I saw what looked to be type support in 
CLI, but it didn't seem very obvious how to use it.

3. Options can have a long name and no short name (flag). This is handy 
for when you have a lot of parameters, and run out of suitable short 
names.

3. Sets of options can be read from and written to properties files.

4. A set of default options is provided (disabled by default) that will 
read properties files during parsing, and write them once parsing is 
completed.

For example:

mycommand --properies-file in.properties --some-other-argument 
some_value --write-properties-file out.properties

reads option values from in.properties, over-rides the value for 
--some-other-argument, and dumps the properties out to out.properties.

The "special" property options names and flags can be fully customised 
via method calls.

5. During interrogation, option values are retrieved via booleanValue, 
stringValue, etc. calls. These are "type-safe", in that trying to 
retrieve a boolean value from an integer option will throw a 
runtime-exception, which will be thrown the first time that the program 
is run
(assuming, reasonably that you go through a create/parse/query phase 
early in program initialisation).

I am pretty sure that most of this functionality could be added to CLI 
without breaking the existing interfaces, and may be useful for some 
people (not requiring a flag for each option, simple typing, and the 
properties file functionality has been very handy for me).

If anyone is interested in this, mail me directly for further info. I'd 
be happy to write patches if people think its a good idea.

    cheers,
          Martin


> Date: Sat, 05 Jan 2002 20:05:40 -0500
> From: David Dixon-Peugh <dp...@mindspring.com>
> Subject: [cli] Suggestions
> Content-Type: text/plain; charset=us-ascii; format=flowed
>
>
>
>
> I've been fooling with the CLI package in the
> Sandbox, and I've got a few suggestions on how
> it might be improved.
>
> #1 - Usage Statement
>
> Since we are setting up the Options class with
> all the option possibilites and their descriptions,
> it seems a logical place to generate a Usage
> statement.
>
> #2 - Default Values on Options
>
> It seems that the default values are known when
> the options are created.  It makes sense to set
> the defaults when the Options object is created.
>
> #3 - Integrate with Properties Object
>
> It would be nice, if I could write something like
> this:
>
> public static void main(String args[]) {
>     Options opt = new QuiltOptions("quilt.properties");
>
>     try {
>       Properties prop = opt.parse( args );
>     } catch (MissingArgumentException e) {
>       System.err.println( opt.getUsageStatement() );
>       System.exit( -1 );
>     }
> }
>
> What do you think?  I think it makes the code look
> an awful lot cleaner than the way it works now.
>
> Thanks,
>
> DDP
>


--
To unsubscribe, e-mail:   
<ma...@jakarta.apache.org>
For additional commands, e-mail: 
<ma...@jakarta.apache.org>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>