Add configurable automatic name mapping from camelCase to kebab-case

[lihaoyi]

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 classes 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

[lefou]

It's always ok to not break compatibility in version bumps. Hence, I'd suggest a 0.6.0 release, as this gives the new feature and the potential break for Scala 3 users more credit.

[lihaoyi]

@lefou if we are going to bump minor versions, should we go and break compatibility just to clean up the code? Or should we just leave it for now for easier scala 2 updates?

[lefou]

@lefou if we are going to bump minor versions, should we go and break compatibility just to clean up the code? Or should we just leave it for now for easier scala 2 updates?

I'd keep it. You already did the work, and it greatly eases adoption of the new version.

[lefou]

Id would be great to have a version with the deprecations.

- @deprecated("Binary Compatibility Shim")
+ @deprecated("Binary Compatibility Shim", "mainargs 0.6.0")

[lihaoyi]

Ok, I turned back on MIMA (which is currently failing) and tweaked the readme to 0.6.0