Features and Ideas

[dcarbone]

Hey there,

First I want to thank you for creating this generator, was a big help.

Secondly, I have created my own implementation of this in php here: dcarbone/json-to-go

I added a few features I needed for various projects, namely:

• Convert simple type (string, int, float, bool) literals into pointers. This is helpful when you need to need to have a trinary state for simple type properties:
  • Populated, non-zero (true)
  • Populated, zero (false)
  • Actually empty (nil)
• Break out nested structs, slices, and maps into separate types
  • Lots of uses, primarily useful when constructing type or using nested type as argument / return type, etc.
• Force ",omitempty" onto everything
  • In conjunction with the aforementioned "pointer" stuff, this can be used to prevent unspecified-but-interpreted zero-val values from causing havoc on upstream API's
• Force int -> float
  • Because js ints are a lie
• Force empty structs to interface{}
  • This can be useful if the example JSON payload has a "{}" in it somewhere, indicating that the response is an object but not giving you specifics.
• Custom callbacks on certain actions. I elected to allow the following to be overloaded:
  • goType: Returns string representation of the go type (struct, slice, interface, etc.). By default my parser, like yours, does not do any sort of "map" or "json.RawMessage" determination as it is impossible to accurately do this automatically. Instead I let the user overload the "type" determination. "map" will lead to a specific type (MapType) while "json.RawMessage" and others will attempt to be created as SimpleType'd items. I might flesh this out if need be.
  • mostSpecificPossibleGoType: I only check for float / int determination, but I'm sure others have more advanced needs.
  • formatPropertyName: I follow your property name formatting system very closely, but I figure let others implement their own formatter if they need
  • toProperCase: Again, I follow your implementation on this but others might want to muck with it.

My use cases for the above generally revolve around mapping request and response types for large api's (hundreds of separate endpoints, which can lead to over a thousand separate models), and wanting to generate them on the fly.

I am not sure how many of these features would be helpful to the world at large, but I wanted to see if any would be of interest to you, and possibly provide ideas for future development.

If one stands out, let me know and I can work on a PR for your JS version.

Thanks again! - Daniel

[mholt]

Hey @dcarbone - thanks for your feedback! Glad you liked it enough to fork and build on it. I did read your post but I need to go through it again in more detail when I have a chance; I do have a few questions on some of those points. Other projects are consuming my time right now, so it might be a while.

[grische]

Force int -> float Because js ints are a lie

If we convert int, in particular int64, to float we will loose precision. This should also cause problems in golang when trying to unmarshall jsons with these kind of numbers. I think the current detection as well as the new detection of #137 is better.

[dcarbone]

The purpose of that conversion is due to the fact that sample input may only contain int-like values, when in fact the value could just be a float with zero precision when serialized.

Precision loss is irrelevant if it fails to unmarshal in the first place :)