Re: [go-nuts] Re: encoding/json: any way to receive number literal "10.0" into integer field?

[Matt Harden]

https://play.golang.org/p/8R6QmYw_28

On Fri, Jun 17, 2016 at 3:08 PM Evan Digby  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.

[go-nuts] Re: encoding/json: any way to receive number literal "10.0" into integer field?

[Evan Digby]

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.