Skip to content
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

Allow to declare options #64

Closed
mrackwitz opened this issue Mar 12, 2016 · 3 comments
Closed

Allow to declare options #64

mrackwitz opened this issue Mar 12, 2016 · 3 comments

Comments

@mrackwitz
Copy link
Member

CLAide already allows declaring some of the attributes on the class itself as summary, description and more or less arguments, while the latter is not fully exposed in a DSL. I think this is inconsistent.
Allowing that would make it also a lot easier defining reusable pieces of the CLI and share them across different subcommands.
CocoaPods uses currently modules for that, but as they have to overwrite the initializer that works only good once and gets messy after that.

This could look like below:

class CoffeeMaker < CLAide::Command
  self.description = 'Make delicious coffee from the comfort of your terminal.'

  self.option '--[no-]milk', :flag, 'Don’t add milk', default: true
  # * parses `--milk` as `true`
  # * parses `--no-milk` as `false`
  # * defines an attribute accessor `milk?`

  self.option ['--sweetner', '-s'], 'sugar|honey', 'Use one of the available sweetners', multivalued: true
  # * parses `-s sugar -s honey` as `['sugar', 'milk']`
  # * parses `--sweetner sugar` as `['sugar']`
  # * defines an attribute accessor `sweetners`
end

This DSL syntax is inspired by Clamp.

@segiddins
Copy link
Member

How would you then remove an option in s subclass?

@mrackwitz
Copy link
Member Author

I could imagine different ways to achieve that.

A: Don't add them in the first place. The interface would be much more composable. So universal subclasses don't necessarily need to define optional options for subclasses and could put them into separate modules.

B: This could be backwards-compatible with the current API. The declared options could be appended to a class variable declared_options, which could be an input to self.options. The latter would still host only an array of pairs with names and descriptions. If an option is removed from the UI, it won't be parsed in later steps. The implicitly defined accessors would be likely still available in that case, which could lead to programmer errors.

C: Class-based option black-listing.

class AeroPress < CoffeeMaker
    self.remove_option '--[no-]milk'
    self.remove_option ['--sweetner', '-s']
end

@segiddins
Copy link
Member

👍🏻 just thought of a cool, totally backwards-compatible way to do this. Will throw up a PR once this play is over.

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

No branches or pull requests

2 participants