New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle positional (non-option) arguments as OptionSpec #17

Closed
kriegaex opened this Issue Jul 27, 2012 · 13 comments

Comments

Projects
None yet
4 participants
@kriegaex

kriegaex commented Jul 27, 2012

In an e-mail I asked a while ago:

I guess that non-option args are a bit of a stepchild for you. I cannot assign them to an option spec, convert them into another type as I go along, define a help text for them etc. I am especially missing the help text. Treating non-options similar to options, enabling them to be used via fluent interface etc. would again save the user a lot of work in validating, converting and assigning those values as well as having to define a help formatter just for non-option parameter help to be displayed.

Paul answered:

When I first created JOpt SImple I didn't have complex command structures in mind, e.g. git's command line. Mostly I'd imagined the typical Unix command line supporting options as switches (--foo, --bar, etc.), and non-option arguments being the things operated on -- file names, or what have you. If there's enough demand and I can think of a way to support it without overcomplicating the API for those cases, I'll certainly consider it.

I think it would be really useful if I could specify a minimum and (optionally) maximum number of positional parameters and optionally also a required type, e.g. File or Integer (default would be String), provided they all have the same type. It is clear that a required type other than String does not make sense if the positionals can have mixed types. I guess file/path (both convertible to java.io.File) are pretty common, though, and thus useful for other people as well. But this is just a side issue.

the main issue is as mentioned above: I would like to have the positionals in a structure like OptionSpec<String[]> or OptionSpec<File[]> or maybe the other way around like OptionSpec<String>[], OptionSpec<File>[] or something fancier like List<OptionSpec<String>>, List<OptionSpec<File>>. Whatever seems convenient to you. The OptionSpec thing would also permit users to add a help text like "books to be downloaded and unpacked" and parameter name like "input_file" from which a help text line like

input_file1 input_file2 ...          books to be downloaded and unpacked

or maybe

input_file*          books to be downloaded and unpacked

could be generated.

@kriegaex

This comment has been minimized.

Show comment
Hide comment
@kriegaex

kriegaex Jul 27, 2012

By the way, this would also enable you to generate a usage line like

ProgramName [options] input_file*

which could be used as a header before the verbose help text.

kriegaex commented Jul 27, 2012

By the way, this would also enable you to generate a usage line like

ProgramName [options] input_file*

which could be used as a header before the verbose help text.

@pholser

This comment has been minimized.

Show comment
Hide comment
@pholser

pholser Dec 19, 2012

Collaborator

Offering up non-option arguments as a type other than String sounds reasonable, as does the attendant help option.

Collaborator

pholser commented Dec 19, 2012

Offering up non-option arguments as a type other than String sounds reasonable, as does the attendant help option.

@ElectricBill

This comment has been minimized.

Show comment
Hide comment
@ElectricBill

ElectricBill Jan 8, 2013

I might be way off-base, but I just decided to use this package and the first thing I looked for was how to code for the non-option associated arguments, aka, positional arguments. Using the NULL pointer for the option name seems a logical thing.

ElectricBill commented Jan 8, 2013

I might be way off-base, but I just decided to use this package and the first thing I looked for was how to code for the non-option associated arguments, aka, positional arguments. Using the NULL pointer for the option name seems a logical thing.

@pholser

This comment has been minimized.

Show comment
Hide comment
@pholser

pholser Jan 8, 2013

Collaborator

@ElectricBill @kriegaex What about this:

class OptionParser {
    <V> OptionSpec<List<V>> parser.convertsNonOptionsTo(Class<V> type);
}

?

You can still get the non-option arguments as Strings via OptionSpec.nonOptionArguments().

Collaborator

pholser commented Jan 8, 2013

@ElectricBill @kriegaex What about this:

class OptionParser {
    <V> OptionSpec<List<V>> parser.convertsNonOptionsTo(Class<V> type);
}

?

You can still get the non-option arguments as Strings via OptionSpec.nonOptionArguments().

@pholser

This comment has been minimized.

Show comment
Hide comment
@pholser

pholser Feb 7, 2013

Collaborator
parser.nonOptions("a longer description").ofType(File.class).describedAs("files");

@ElectricBill @kriegaex If OptionParser were to support this construction, how would you imagine the default help formatting would display the description of the non-option arguments, if at all?

I'm imagining:

Non-option arguments:
[files: File] -- a longer description
Collaborator

pholser commented Feb 7, 2013

parser.nonOptions("a longer description").ofType(File.class).describedAs("files");

@ElectricBill @kriegaex If OptionParser were to support this construction, how would you imagine the default help formatting would display the description of the non-option arguments, if at all?

I'm imagining:

Non-option arguments:
[files: File] -- a longer description

pholser added a commit that referenced this issue Feb 17, 2013

@pholser

This comment has been minimized.

Show comment
Hide comment
@pholser

pholser Mar 1, 2013

Collaborator

@ElectricBill @kriegaex Have a look at the preceding and let me know what you think. May release a 4.5 beta soon.

Collaborator

pholser commented Mar 1, 2013

@ElectricBill @kriegaex Have a look at the preceding and let me know what you think. May release a 4.5 beta soon.

@kriegaex

This comment has been minimized.

Show comment
Hide comment
@kriegaex

kriegaex Mar 4, 2013

Sorry, @pholser, for being unresponsive. I have been quite busy with Scrum coaching lately, gonna test the latest version one of the next weekends. Knowing your work, I guess your implementation is probably fine and useful. Stay tuned for more substantial feedback...

kriegaex commented Mar 4, 2013

Sorry, @pholser, for being unresponsive. I have been quite busy with Scrum coaching lately, gonna test the latest version one of the next weekends. Knowing your work, I guess your implementation is probably fine and useful. Stay tuned for more substantial feedback...

@pholser

This comment has been minimized.

Show comment
Hide comment
@pholser

pholser Mar 4, 2013

Collaborator

@kriegaex No worries -- sorry I didn't get to this sooner too. Thanks for your help!

Collaborator

pholser commented Mar 4, 2013

@kriegaex No worries -- sorry I didn't get to this sooner too. Thanks for your help!

@pholser

This comment has been minimized.

Show comment
Hide comment
@pholser

pholser Mar 25, 2013

Collaborator

Considering also adding NonOptionArgumentSpec.atMost(max) and atLeast(min), to verify the number of non-option arguments.

Collaborator

pholser commented Mar 25, 2013

Considering also adding NonOptionArgumentSpec.atMost(max) and atLeast(min), to verify the number of non-option arguments.

pholser added a commit that referenced this issue Apr 3, 2013

For #17, add NonOptionArgumentSpec.withValuesConvertedBy().
Undoing NonOptionArgumentSpec.at(Lea|Mo)st.
@pholser

This comment has been minimized.

Show comment
Hide comment
@pholser

pholser May 9, 2013

Collaborator

@kriegaex @ElectricBill Unless there are objections, I'll close this and plan on releasing it in 4.5. Thanks!

Collaborator

pholser commented May 9, 2013

@kriegaex @ElectricBill Unless there are objections, I'll close this and plan on releasing it in 4.5. Thanks!

@roji

This comment has been minimized.

Show comment
Hide comment
@roji

roji Jul 2, 2014

Sorry to post on such an old issue, but I was wondering if there's a way to work with non-option arguments which aren't of the same type (program ). Right now it seems it's only possible to have a list of non-option arguments of the same type, and at most limit their minimum/maximum occurrences?

roji commented Jul 2, 2014

Sorry to post on such an old issue, but I was wondering if there's a way to work with non-option arguments which aren't of the same type (program ). Right now it seems it's only possible to have a list of non-option arguments of the same type, and at most limit their minimum/maximum occurrences?

@pholser

This comment has been minimized.

Show comment
Hide comment
@pholser

pholser Jul 2, 2014

Collaborator

Hi @roji -- Currently there isn't a way to declare non-option arg 1 of one type, arg 2 of another type, and so forth. Your best bet is probably to treat all the non-option args as Strings and do whatever type conversion you need.

    OptionParser parser = new OptionParser();
    OptionSpec<String> nonOptionSpec = parser.nonOptions();
     // ...

    OptionSet options = parser.parse();

    List<String> nonOptions = options.valuesOf(x);
    // 
Collaborator

pholser commented Jul 2, 2014

Hi @roji -- Currently there isn't a way to declare non-option arg 1 of one type, arg 2 of another type, and so forth. Your best bet is probably to treat all the non-option args as Strings and do whatever type conversion you need.

    OptionParser parser = new OptionParser();
    OptionSpec<String> nonOptionSpec = parser.nonOptions();
     // ...

    OptionSet options = parser.parse();

    List<String> nonOptions = options.valuesOf(x);
    // 
@roji

This comment has been minimized.

Show comment
Hide comment
@roji

roji Jul 2, 2014

Thanks for the quick response, this is definitely a pain point for me...

Python's argparse module handles this quite elegantly, positional arguments are defined just like switch arguments (https://docs.python.org/dev/library/argparse.html). Seems like joptsimple could do something very similar.

roji commented Jul 2, 2014

Thanks for the quick response, this is definitely a pain point for me...

Python's argparse module handles this quite elegantly, positional arguments are defined just like switch arguments (https://docs.python.org/dev/library/argparse.html). Seems like joptsimple could do something very similar.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment