Configuration objects in Scallop

It turned out that spreading type annotations throughout all the code in all places where options are requested is not a good idea. And, of course, it is prone to errors - who likes those type annotations?

When using such option parsing libraries, users usually end up creating a big object with fields corresponding to each option:

object Conf {
  var apples:Int = 0
  var bananas:Int = 0
}
// ... parsing options ...
Conf.apples = parser.getOption("option name", ...)
Conf.bananas = parser.getOption("other option name", ...)

Sure, this works, and usually flexible enough - but why would anybody want to create such boilerplate? And by the way, nobody likes var's in their code :)

So in Scallop, I needed to cut down that unnecessary repetition. There are several ways:

• Create a compiler plugin. The most powerful option. And the least enjoyable - even given the ease of installing a compiler plugin using sbt, I doubt that anybody will install compiler plugin just to parse the command-line options.
• Use macroses. Great choice, but it seems that it would not work for a long time - SIP-16 didn't make it into 2.10 (only behind -Xexperimental option). That and the fact that people are often scared of macroses :)
• Mix that conf object creation with option definition. I decided to go with this choice, at least while we do no have those macroses.

So the following is an example of the result:

object Conf extends ScallopConf(List("-a","3","-b","5","tree")) {
  val apples = opt[Int]("apples")
  val bananas = opt[Int]("bananas")
  verify
}
Conf.apples() // 3
Conf.bananas.get // Some(5)

The only problem here is that "val apples" contains not the value itself, but the ScallopOption[Int] instance. To extract the actual value, you will need to call either .apply() method (returns a value), or .get method (returns the value as an Option). 

ScallopOption is needed to wait until the rest of the option set is defined - since if you try to get the value on-the-spot, the parser will know nothing about the "bananas" option and the trailing argument - which can result in some bad things sometimes.

To protect you from this scenario, ScallopConf checks that .verify method was called before any options are extracted. So if you want to define some custom extractor for value, you'll need to either use a lazy val, or define your extractor after the .verify call:

object Conf extends ScallopConf(List("-a","3","-b","5","tree")) {
  val applesO = opt[Int]("apples")
  lazy val apples = apples.get.map(a => if (a > 3) "plenty" else "few").getOrElse("zero")
  val bananas = opt[Int]("bananas")
  val name = trailArg[String]()
  verify
  val bananasValue = bananas() + 3
}
Conf.apples // "few"
Conf.bananasValue // 8

This will work, and type-safety is still in place, but inventing another name for an extractor or suffixing the option value with something looks ugly. We surely can do better :)

In fact, ScallopOption is just a laziness wrapper around standard Option - that is, it batches all operations on it, and evaluates the value as the last resort measure. It has most of standard Option methods defined - like .map, .orElse, .collect, etc.

So that snippet can be written a bit cleaner (without lazy vals and redundant val names):

object Conf extends ScallopConf(List("-a","3","-b","5","tree")) {
  val apples = opt[Int]("apples").map(a => if (a > 3) "plenty" else "few").orElse(Some("zero"))
  val bananas = opt[Int]("bananas").map(3+)
  val name = trailArg[String]()
  verify
}
Conf.apples() // "few"
Conf.bananas() // 8

Almost perfect. It is so close to complete boilerplate-lessness, that the advantages of the macro in place of all this are quite questionable.

But there are still some advantages - notice that "apples" is appearing twice on that line: in a val name and in the option definition itself. And forcing the programmer to remember to extract the options in the right place isn't good either.

So, wait for the macro version :)

The code is located on github, the apidocs are there as well, comments, suggestions, and forks are all welcome!