Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add configurable automatic name mapping from
camelCase
to `kebab-ca…
…se` (#101) Fixes #16 * We maintain backwards compatibility by continuing to allow the `camelCase` names in addition to the `kebab-case` names during argument parsing. * When a an explicit `name = ???` is given to the `@main` or `@arg` annotation, that takes precedence over everything, and is not affected by the name mapping, * Name mapping is configurable by passing in `nameMapper = mainargs.Util.snakeCaseNameMapper` or `nameMapper = mainargs.Util.nullNameMapper` when you call `ParserForClass` or `ParserForMethods` * I had to add a whole bunch of annoying shims to maintain binary compatibility when threading the new `nameMapper` through all our method signatures. That would be resolved by a proposal like https://contributors.scala-lang.org/t/can-we-make-adding-a-parameter-with-a-default-value-binary-compatible/6132/3, which alas does not exist yet in the Scala implementation * The duplication in method argument lists is getting very annoying. Again, this would be solved by a proposal like https://contributors.scala-lang.org/t/unpacking-classes-into-method-argument-lists/6329, which still doesn't exist in the language * Bumping to 0.6.0 since we cannot maintain bincompat for Scala 3 and Scala 2 simultaneously * There is no way to continue to evolve the `case class`es that is compatible with both Scala 2 and Scala 3, due to differing method signature requirements. e.g. `def unapply(x: MyCaseClass): Option[Tuple]` vs `def unapply(x: MyCaseClass): MyCaseClass`. * The choice is either to break bincompat in Scala 2 or break bincompat in Scala 2, and I ended up choosing to do so in Scala 2 since those would have the larger slower-moving codebases with more of a concern for binary compatibility * Updated the docs and added coverage in the unit tests * I intend to release this as 0.5.5 once it lands
- Loading branch information