https://play.golang.org/p/8R6QmYw_28
On Fri, Jun 17, 2016 at 3:08 PM Evan Digby <evandi...@gmail.com> wrote: > To further this, if you do need your internal model to be a concrete > struct rather than interface this approach still fits: > > https://play.golang.org/p/_wrgN1FltA > > > On Friday, 17 June 2016 15:02:43 UTC-7, Evan Digby wrote: >> >> One approach to deal with this would be to abstract your internal model >> as an interface from the model you receive and mutate them to match. This >> also gives you the power to truncate/round/mutate a float however best >> suites your needs rather than hoping the library truncates/rounds/mutates >> in a way that meets your requirements. >> >> https://play.golang.org/p/d97ElsNa_o >> >> You could limit your internal model to just the information you need, and >> in a format that better matches your requirements than the structure >> dictated by the message producer. >> >> There is of course overhead to this solution, but in many many (not all) >> applications this approach is worth the overhead of matching the producer's >> data format to your interface. >> >> It'll allow you to easily tack on new sources of data (if that's ever a >> requirements). If they do change their format, you don't have to change all >> of your downstream code. You just have to change the implementation of the >> SAME interface to match the new source data. >> >> On Friday, 17 June 2016 14:37:19 UTC-7, Jonathan Gold wrote: >>> >>> We have an upstream provider of JSON data which sends integer data >>> types as floating point literals with a "0" decimal part. By default >>> json.Decoder doesn't allow this and fails: >>> >>> https://play.golang.org/p/MEJlg1n3vs >>> >>> Unfortunately this provider is almost certain not to change this, and >>> so we just have to deal with it as clients of their API. What are some >>> ways we could handle this? >>> >>> Things that come to mind: >>> >>> - Submit a change to encoding/json that allows us to set some sort >>> of number processing function to customize its behavior (or to >>> set some sort of policy which allows number literals ending in >>> \.0*$ for integer targets) >>> >>> - Create a custom io.Reader which wraps in input stream by reading >>> individual tokens from it using an internal json.Decoder, and >>> then emits number literals without trailing ".0". >>> >>> - Buffer all inbound decodes into a map[string]interface{} and set >>> the decoder to UseNumber(), and then replace those json.Numbers >>> with corrected ones, then serialize back and decode once more >>> into the destination (this is similar to the token-stream >>> approach above) >>> >>> Are there other approaches I'm overlooking? >>> >>> jonathan >>> >> -- > 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. > -- 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.
