Re: [cli] Suggestions

[John Keyes]

Hi Martin,

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).

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.

Check out this unit test which shows how to use typed options:
http://cvs.apache.org/viewcvs.cgi/jakarta-commons/cli/src/test/org/ apache/commons/cli/PatternOptionBuilderTest.java?rev=1.6&content- type=text/vnd.viewcvs-markup

2. 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.

This is possible in CLI, e.g. OptionBuilder.withLongOpt( "username" ).hasArg().create().

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

No support for this.  I have a TODO for myself (I must document it) to
have an XML reader and writer for configuring an Options instance.  I
will document this TODO and also add yours.  If you feel like having a
bash at the properties one that would be cool ;)

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.

Might be that I'm a bit sleepy but I don't see what this achieves. Can you
enlighten me please.

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).

The TypeHandler class does provide support for this at the interrogation
stage.  Have a look at it and tell me if there is anything you think is
missing.

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.

I'm glad you found CLI Martin, saves creating another package ;) Let me know if you
have any other queries/comments.

BTW, this is the first time I have seen Davids mail as well.

-John K

   cheers,
         Martin

Date: Sat, 05 Jan 2002 20:05:40 -0500
From: David Dixon-Peugh <[EMAIL PROTECTED]>
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: <mailto:commons-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>

- - - - - - - - - - - - - - - - - - - - - - -
Jakarta Commons CLI
http://jakarta.apache.org/commons/cli


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>