Add @HoconName annotation

[ihostage]

Current implementation doesn't give users any chance to control the property name in Hocon representation when they use the useConfigNamingConvention.

[ihostage]

This test was successful only because the value in @SerialName is follow the naming convention 😄
I think it is confusing and not helpful to check anything.

[ihostage]

@sandwwraith, have I a chance to get review and merge this fix?
I can't continue my work on the config4k library without it. 😞

[sandwwraith]

I'm a little bit hesitant to add this annotaiton for Hocon, since we do not have a Json equivalent; if same problem arises in Json (it is there for JsonNamingStrategy, for example), maybe we would need a better generalized solution.

What are benefits of having this annotation instead of just disabling "useHoconNamingConvention"? Or maybe we need a specific annotation, e.g., @DisableHoconConvention instead? I imagine it can be quite confusing if I had @HoconName("fooBar") @SerialName("fooBar") on the same property

[ihostage]

What are benefits of having this annotation instead of just disabling "useHoconNamingConvention"?

I don't want to disable this naming convention, because 99% of the fields follow this convention. However, we also need the ability to set a serial name manually from time to time. 🤷‍♂️

Or maybe we need a specific annotation, e.g., @DisableHoconConvention instead?

Yes, potentially this solves the problem by using two annotations per field, but it doesn't look so good either. 🤔

@Serializable
data class (
  @DisableHoconConvention
  @SerialName("unConventionField") 
  val unConventionField: String
)

I imagine it can be quite confusing if I had @HoconName("fooBar") @SerialName("fooBar") on the same property

Do you mean the situation where one type can be serialized in multiple formats?

since we do not have a Json equivalent

We have the @JsonNames annotation as an alternative name for fields. Perhaps using alternative names instead of overriding the serial name with a special annotation would be a more preferable approach for you. 🤔

[pdvrieze]

I have looked the options for not having per-format naming annotations. I am not sure that those annotations can be avoided if you want to be able to use the same serializers for different formats (with potentially different names). Even if a functional strategy is used, it would often have to resort to either a built-in translation table or custom annotations.

[sandwwraith]

@ihostage

Do you mean the situation where one type can be serialized in multiple formats?
Yes. In case I have a class serialized both to Hocon and Json, it is possible to end up in this situation. Although it can indeed be quite rare.

We have the @JsonNames annotation as an alternative name for fields

It works for deserialization alone. @HoconName though affects encoding as well. If you think that this problem is specific to deserialization, yes, @JsonNames analogue would be preferable.

[ihostage]

It works for deserialization alone. @HoconName though affects encoding as well. If you think that this problem is specific to deserialization, yes, @JsonNames analogue would be preferable.

@sandwwraith I think in most cases, it's related to deserialization. However, without the ability to set the property name directly for serialization, it seems strange. I still have an opinion that the useConfigNamingConvention is implemented with a bug, and I need your decision on how to fix it 🤷‍♂️
What we discussed previously:

1. @HoconName for both ways (current implementation in this PR)
2. @HoconNames only for deserialization
3. @DisableHoconConvention @SerialName for both ways
4. @HoconNames [@DisableHoconConvention] for both ways, but optimized as a single annotation for deserialization, as the most frequently case.
5. Your option