feature-Request: hyphen-separated settings

[shiphrah]

HOCON specification recommends hyphen-separated settings over camelCase

Using case classes like the following works

    case class MySetting(`hyphen-separated-setting`: String)

but it is a bit clumsy in the source code.

Wouldn't it be nice to have an option to automagically convert camelCase into hyphen-separated?

[ceedubs]

You raise a good point, @shiphrah.

In general, I am not a big fan of "magic". In fact, I somewhat regret some of the macro magic that Ficus already has. Having said that, the macro-derived readers are pretty convenient compared to generating readers manually. It probably makes sense to support something like this.

I have a number of things on my backlog, so I probably won't be getting around to this very soon. In case someone else wants to take a stab at a pull request, here are my initial thoughts:

• The underlying macro implementation can take an argument that will determine whether to convert to hyphen-separated.
• I'd prefer not to break the current behavior of importing ArbitraryTypeReader._, so a separate object could be defined with an implicit def for the hyphentating implementation.
  • This breaks type class global uniqueness, which I think is kind of evil. But I would guess that the majority of people using Ficus care more about verbosity than type class global uniqueness. People can feel free to weigh in on this GitHub issue with their thoughts.
• There are some rules I don't know when converting camelCase to hyphen-separated. For example, does targetURL become target-url or target-URL? I imagine there is some trusted implementation of these conversions somewhere, and we may want to consider whether it's worth adding as a dependency.

I've been sitting on some ideas for making it much easier to define readers so it's easier to not rely on macros and still not need to write lots of boilerplate. However, these ideas would probably be significant enough that they would be part of a Ficus 2.0, and I'm not sure if/when that would happen.

[shiphrah]

Thanks for your comments, @ceedubs !

Actually I'm still quite biased about my feature request. The approach using literal identifiers in the case classes works for me and my IDE supports them well -- just in pretty-printing I have to replace the generated $minus again. Although I prefer hyphenated-settings for readability and because of the HOCON recommendation, one could argue that camelCase would be acceptable for scala-ish settings. sbt seems to move to camelCase too. I would love to hear, what others think about this subject...

The ability of Ficus to directly read case classes saves me from a lot of boilerplate. So I would not want to miss this feature.

Having said all this, I still think it could be a nice feature being able to customize how Ficus translates from fields to settings, without having to generate readers manually. I'm wondering if would be possible to provide an (implicit) String => String for this purpose.

I can try to have a look at this, but will not manage before the 4th quarter of the year. Still I have no experience with macros, so I don't know how far I would get without support...

Jürgen