Mapping field names based on a constant function

[kyri-petrou]

Hi there 👋 First, thank you very much for your work on this library, it's honestly amazing!

I'm not sure whether this is already supported or not, but I was wondering whether it's possible to map from one enum / case class to another applying a constant function to map the field names.

Example:

enum size:
  case small, large

enum Size:
  case Small, Large

In such case, one could transform size -> Size by mapping the field names using the .capitalize method.

Is something like this currently supported by the library? One usecase for this is that API models might use different notations (kebab-case vs snake-case, etc) than DAOs. It would be amazing if there was a way to do this transformation without having to explicitly map all the fields manually!

[kyri-petrou]

Also, please let me know if you prefer in the future to open issues like this as a discussion or ask them via a different channel (discord, etc)

[arainko]

So yeah, this thing is kinda hard to implement properly - I can imagine an implementation where a user supplies an inlined String to String function that the library can then match on (effectively creating a set of 'blessed' String operations that can be then reconstructed during compile time into a field name transformation.

The problem with this is this doesn't allow users to define their own transformations (i.e. ones that are made of non-blessed methods) and will inherently put the pressure back on the maintainers to bless more and more operations (the answer to this is probably to support only the most 'general' transformations, like the ones you've mentioned: kebab-case to snake_case, kebab-case to camelCase etc. but that also feels kind of unsatisfactory).

Nevertheless I can see this being handy in some cases so I'll definitely put some thought into trying to implement it after I'm done with 0.2.0 😄

As for the second question, it's completely fine to ask feature-requesty questions here 👍

[kyri-petrou]

Thank you very much for the explanation! Totally understand the challenges in implementing this, so I also understand if you decide not to pursue implementing this any time in the near future. PS: I'd be happy to contribute, but my knowledge of macros is extremely little. With some pointers I might be able to at least get some of the groundwork done though!

the answer to this is probably to support only the most 'general' transformations, like the ones you've mentioned: kebab-case to snake_case, kebab-case to camelCase etc. but that also feels kind of unsatisfactory

Just my two cents on this comment: I think that while it might feel unsatisfactory, it's the approach that many JSON libraries have also taken (circe, jsoniter, etc). Personally, I think it's a good compromise, since I don't think there are many more use-cases for transforming all fields based on a single kind of transformation

[arainko]

Sooo after giving it some thought, I think this will nicely fit into my backend redesign after 0.2.0 lands, I'll try to pursue this as soon as the work on 0.2.0 is done 😄 Dunno how long that will be tho (I'm currently aiming for a release somewhere around new years eve, but we'll see how that turns out) 🤷