search

trevorld / r-optparse

command-line optional argument parser
http://trevorldavis.com/R/optparse/dev/
GNU General Public License v2.0
146 stars 11 forks source link

Add parameter positional_arguments to OptionParser constructor #6

Open krlmlr opened 10 years ago

krlmlr commented 10 years ago

I think this information really belongs there, and not in parse_args. This would also provide an easy way to deprecate passing FALSE to positional_arguments.

trevorld commented 10 years ago

Yeah, the information should be in OptionParser instead of parse_args but there won't be alot of value added in making the switch unless I also used that information to write a more informative usage statement which I don't plan on doing anytime soon especially since argparse already automatically adds positional arguments to usage statements.

Unless CRAN improves their package dependency versioning capabilities I probably won't ever deprecate passing FALSE to positional_arguments although making it redundant if present in OptionParser wouldn't break backwards compatibility.

krlmlr commented 10 years ago

You can specify a minimum required version for a dependency. Is that not enough?

A more informative usage statement would mean saying usage = default_usage(positional_arguments) in the definition of the OptionParser function. Would you care for a pull request?

trevorld commented 10 years ago

You can specify a minimum required version for a dependency. Is that not enough?

No, you'd want users to be able to specify which stable set of API's they want according to semantic versioning (i.e. (1.0 <= optparse < 2.0) so users wouldn't have to use the new function calls if they don't want to. Then if I break backwards compatibility (hence bumping version number to at least 2.0) users don't need to change their code other then saying they only want the latest 1.* version. CRAN doesn't allow you to also set a maximum version number for a package dependency nor in a library call.

A more informative usage statement would mean saying usage = default_usage(positional_arguments) in the definition of the OptionParser function. Would you care for a pull request?

Exactly. I would welcome a pull request that implemented this as long as backward compatibility with the last version released on CRAN wasn't broken In particular this means that if positional_arguments was not set in OptionParser then positional_arguments set to TRUE or FALSE (default) in parse_args works as before however if positional_arguments is set in OptionParser then the second set of positional_arguments set in parse_args could either be ignored or throw an error or warning if not FALSE. Easiest way to see if it was set would probably be to set the default to NULL.