Me too I have to add struct tags to over 300 objects, repeating the same 
text in a different style, totally unproductive and annoying work which the 
computer should do for me.

In the end I've used a tool that parses the .go files and adds the tags 
automatically, although that resulted in dozens of structs that don't need 
to be encoded to have tags too for no reason.

I truly believe the json library should have a setting we can set on the 
Encoder to automatically format the output in snake/camel/anycase for the 
api user preference.

On Tuesday, March 6, 2018 at 5:24:47 AM UTC+1, Alex Buchanan wrote:
>
> I'm bummed there still isn't a good solution for this. It seems like such 
> an easy and extremely common thing. In a decade of webdev, I've possibly 
> never seen a JSON API with Golang style UpperCamelCase keys.
>
> Is there a solution to this that I'm missing? 
>
> Here's one project I'm working on where dozens of types need to have 
> JSON/YAML formats: https://godoc.org/github.com/buchanae/cwl
>
> Every single struct field needs a really obvious duplication of the field 
> name in the tags, just in camel case. There are 3-4 variable name styles 
> that would cover a majority of the data out there: camelCase, snake_case, 
> etc. (Maybe I should do a code crawling exercise and get some numbers on 
> how often tags are an obvious conversion of the field name...)
>
> My documentation and code would rejoice if encoding/json added a callback 
> for formatting the key name.
>
> Can we just add a call to a callback here? 
> https://golang.org/src/encoding/json/encode.go#L1110
>
>
>
>
>
> On Monday, July 7, 2014 at 12:22:08 AM UTC-7, Dave Cheney wrote:
>>
>>
>>
>> On Saturday, 5 July 2014 18:36:06 UTC+10, i...@bodokaiser.io wrote:
>>>
>>> Hello,
>>>
>>> I would like to have all field names of a struct lower cased by default. 
>>> At the moment I define the lowercased field name as json tag:
>>>
>>> type FooBar struct {
>>>     Id string `json:"id"`
>>> }
>>>
>>> However with bson-, validation-, database- and xml-tags the space is 
>>> getting very very tight.
>>>
>>
>> Why is space tight ? Do you need to use a smaller font ?
>>
>> Seriously for moment, tags are the _correct_ solution for this. Apart 
>> from a potential aesthetic issue, is there a specific reason why you don't 
>> want to use them ?
>>  
>>
>>>
>>> Is there some hack how to implement the Unmarshaler Interface with just 
>>> lowercasing all field names before proceeding?
>>>
>>> Bo
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to