Replace go-simplejson with jason

[Christoffer Gamrath]

jason is a new Go package for dealing with arbitrary JSON, like go-simplejson. However, I find its API more pleasant to use, wherefore I would like to replace go-simplejson with jason. It's easy to refactor code using go-simplejson to jason, and it is even possible to pretty much avoid changing existing code by simply marshalling the jason object to a []byte of JSON and unmarshalling it into go-simplejson.

I am currently working on refactoring go-mwclient to use jason in a local branch, and I'll probably go ahead and push it to the master branch when it's done. I promised in the readme that I would do breaking changes if I found a nicer way of doing something, but I still feel kind of guilty about it. After this, however, I do not expect any more major breaking changes.

[Gary Houston]

I'd encourage any changes that make working with JSON easier. Decoding the
data sent by Mediawiki is a somewhat tedious process where it seems you are
never quite sure what the format of the next layer of data will be. I
suppose it goes back to a weakness in the Go type system, that dynamic data
must be represented by interface {}, and it isn't much better than void *
in C.

On 3 May 2015 at 01:07, Christoffer G. Thomsen [e-mail]
wrote:

jason https://github.com/antonholmquist/jason is a new Go package for
dealing with arbitrary JSON, like go-simplejson
https://github.com/bitly/go-simplejson. However, I find its API more
pleasant to use, wherefore I would like to replace go-simplejson with
jason. It's easy to refactor code using go-simplejson to jason, and it is
even possible to pretty much avoid changing existing code by simply
marshalling the jason object to a []byte of JSON and unmarshalling it into
go-simplejson.

I am currently working on refactoring go-mwclient to use jason in a local
branch, and I'll probably go ahead and push it to the master branch when
it's done. I promised in the readme that I would do breaking changes if I
found a nicer way of doing something, but I still feel kind of guilty about
it. After this, however, I do not expect any more major breaking changes.

Reply to this email directly or view it on GitHub
#5.

[Christoffer Gamrath]

Thank you for the feedback. I believe that the benefits of switching to
jason outweigh the negatives of breaking compatibility, and that it is
better to do it sooner rather than later.

The benefit of jason is that it lets you stay within its framework right
up to the moment that you assert to a Go type. For example, if you want
to iterate over a JSON object or array, with go-simplejson your only
choice is to cast it to a map[string]interface{} or []interface{}, and
that's not pleasant to deal with when there are multiple layers below
because you've left the framework. I recently wrote some code like that,
and I did not enjoy it. With jason you can cast to a map or array of
jason types instead of interface{}.

On 2015-05-03 00:40, garyhouston wrote:

I'd encourage any changes that make working with JSON easier. Decoding the
data sent by Mediawiki is a somewhat tedious process where it seems you are
never quite sure what the format of the next layer of data will be. I
suppose it goes back to a weakness in the Go type system, that dynamic data
must be represented by interface {}, and it isn't much better than void *
in C.

On 3 May 2015 at 01:07, Christoffer G. Thomsen [e-mail]
wrote:

jason https://github.com/antonholmquist/jason is a new Go package for
dealing with arbitrary JSON, like go-simplejson
https://github.com/bitly/go-simplejson. However, I find its API more
pleasant to use, wherefore I would like to replace go-simplejson with
jason. It's easy to refactor code using go-simplejson to jason, and it is
even possible to pretty much avoid changing existing code by simply
marshalling the jason object to a []byte of JSON and unmarshalling it
into
go-simplejson.

I am currently working on refactoring go-mwclient to use jason in a local
branch, and I'll probably go ahead and push it to the master branch when
it's done. I promised in the readme that I would do breaking changes if I
found a nicer way of doing something, but I still feel kind of guilty
about
it. After this, however, I do not expect any more major breaking changes.

Reply to this email directly or view it on GitHub
#5.

—
Reply to this email directly or view it on GitHub
#5 (comment).