5 ms·

Package encoding/json from the standard library can decode to objects ("Object" in the Java sense, "void *" in the C++ sense) like json_decode does. It also ca

by agentS 14y ago

Package encoding/json from the standard library can decode to objects ("Object" in the Java sense, "void *" in the C++ sense) like json_decode does. It also can decode directly into typed structures. An example from the documentation (you'll have to open the linked example): http://golang.org/pkg/encoding/json/#example_Decoder http://golang.org/pkg/encoding/json/#example_Decoder Anecdotally, a typed version of JSON decoding is much nicer to work with.

lucian303 14y ago
"Anecdotally, a typed version of JSON decoding is much nicer to work with." How so? Considering that JSON isn't strongly typed.
- agentS 14y ago
  Indeed JSON is not strongly typed. However, in practice, every API, every data exchange format I've ever seen or used has used JSON in a strongly typed fashion. i.e. they say "the returned object will have a key of 'foo' with a number as the value, and a key of 'bar' with an array of strings as the value. Why is this nicer? Let's say you are working with the Reddit API. You can, of course, do it the way you suggested, and just decode the result into an untyped object. However, I find this incredibly brittle. You end up with strings indexing into arrays all over the place. On the other hand, when you decode into a Go struct, you use the regular dot syntax to access parameters. You can't misspell these or use the value inappropriately (trying to loop over a JSON number, for example). You can write comments on the fields to document what you expect various values to hold. It is nicer in the same sense that using classes is nicer than just using arrays for everything. Another benefit is of course the improvement of performance. Accessing an string value in a JSON object by a key is the equivalent of a hash table lookup in Python or PHP. It is incrementing a pointer by a constant number in Go (assuming you use strongly typed decoding). I'll say it again, Go's encoding/json can do what you want (the equivalent of json_decode). There are better alternatives available to users of that package, and the GP was discussing how to exploit one of those better alternatives without having to write the struct by hand (which I personally find a trivial one time cost).
  - lucian303 14y ago
    json_decode() without the second param or with it as false will create an object for you that is typed, loosely only if you mess with it afterwards. So what is the advantage other than speed? If I'm CPU bound, then yes, it's worth a look just as many other alternatives are worth a look. But that is a whole different issue.
    - kkowalczyk 14y ago
      Speed is pretty important. Compiler telling you about a bug because you have a typo in your code (as opposed to blowing up at runtime, sometimes in a way that you won't notice) is also important. Struct definition is also a documentation of your data. Another developer (or you a month from now) doesn't have to go back and re-read, say, Redit API docs. He (or you) can just re-read definition of the struct and know all the data that a given JSON request provides. That's nice. An editor can parse the struct definition and give you auto-complete, which is also nice.
      - lucian303 14y ago
        Really? Another static vs dynamically typed language argument? Not this year.
    - agentS 14y ago
      > json_decode() without the second param or with it as false will create an object for you that is typed, loosely only if you mess with it afterwards. First, let me point out that we have moved on to a slightly different topic. The tools that json_decode gives you is available in Go (it would be syntactically awkward, out of a necessity born of Go being statically typed). An example: http://play.golang.org/p/OvshdY1oVQ http://play.golang.org/p/OvshdY1oVQ However, I would write it as follows http://play.golang.org/p/pODFi9Jrve http://play.golang.org/p/pODFi9Jrve. This is merely a different way of doing the same thing. Now, to the topic that we are talking about is the claim that the latter is nicer. I was not comparing PHP and Go when I said that it was nicer (although I have some experience with PHP). I was drawing from my experience with working with JSON in statically typed languages. In particular, working with JSON in C++, Objective-C and Go. In all of these languages, the JSON libraries I used were essentially dynamically typed. I claimed merely that having the JSON library use reflection to deserialize into typed structures is nicer than using NSDictionary's various methods or maps in C++. In PHP, the syntactic overhead of walking dynamic structures is obviously much lower than the languages I was thinking about, so that criticism is blunted when referring to that language. But I still believe there is some advantage there. A large part of what I find nicer about the latter is indeed the same reason I prefer static typing to dynamic typing. It is impossible to mistype the latter (try changing the ".Foo" to ".Fo" and trying to run the snippet). Consider that doing the equivalent in PHP will simply return NULL (I think), as it is really just doing a dictionary lookup. I fully admit that this is a static versus dynamic thing, not about JSON in particular. As to the performance thing, I think you too easily discount the importance of low latency. But regardless, I was really comparing to Go's statically typed brethren. They essentially use hashtables for representing parsed JSON objects which is far less than ideal. Note that they don't employ the clever tricks that dynamic languages use. V8, for example, makes JS's objects (which are essentially hashtables) perform significantly better than a mere hashtable.
- FuzzyDunlop 14y ago
  I think it's nice that you can basically document the expected response, in the form of creating a type with a struct. In pseudo-code-ish: type FacebookUser struct { ProfileID int Name string .... } json.Unmarshal(response, FacebookUser) Compare it to the implementations that just give you a hash: json_decode($response); json.parse response Yeah, you can document it with comments, or visit the API documentation, but you can fix the code and let your comments go stale. You fix both your documentation and your implementation in one go in the first example. It's certainly why I find it more appealing, anyway. Makes me feel more secure in my code.

by agentS 14y ago

lucian303 14y ago

"Anecdotally, a typed version of JSON decoding is much nicer to work with." How so? Considering that JSON isn't strongly typed.

agentS 14y ago
Indeed JSON is not strongly typed. However, in practice, every API, every data exchange format I've ever seen or used has used JSON in a strongly typed fashion. i.e. they say "the returned object will have a key of 'foo' with a number as the value, and a key of 'bar' with an array of strings as the value. Why is this nicer? Let's say you are working with the Reddit API. You can, of course, do it the way you suggested, and just decode the result into an untyped object. However, I find this incredibly brittle. You end up with strings indexing into arrays all over the place. On the other hand, when you decode into a Go struct, you use the regular dot syntax to access parameters. You can't misspell these or use the value inappropriately (trying to loop over a JSON number, for example). You can write comments on the fields to document what you expect various values to hold. It is nicer in the same sense that using classes is nicer than just using arrays for everything. Another benefit is of course the improvement of performance. Accessing an string value in a JSON object by a key is the equivalent of a hash table lookup in Python or PHP. It is incrementing a pointer by a constant number in Go (assuming you use strongly typed decoding). I'll say it again, Go's encoding/json can do what you want (the equivalent of json_decode). There are better alternatives available to users of that package, and the GP was discussing how to exploit one of those better alternatives without having to write the struct by hand (which I personally find a trivial one time cost).
- lucian303 14y ago
  json_decode() without the second param or with it as false will create an object for you that is typed, loosely only if you mess with it afterwards. So what is the advantage other than speed? If I'm CPU bound, then yes, it's worth a look just as many other alternatives are worth a look. But that is a whole different issue.
  - kkowalczyk 14y ago
    Speed is pretty important. Compiler telling you about a bug because you have a typo in your code (as opposed to blowing up at runtime, sometimes in a way that you won't notice) is also important. Struct definition is also a documentation of your data. Another developer (or you a month from now) doesn't have to go back and re-read, say, Redit API docs. He (or you) can just re-read definition of the struct and know all the data that a given JSON request provides. That's nice. An editor can parse the struct definition and give you auto-complete, which is also nice.
    - lucian303 14y ago
      Really? Another static vs dynamically typed language argument? Not this year.
  - agentS 14y ago
    > json_decode() without the second param or with it as false will create an object for you that is typed, loosely only if you mess with it afterwards. First, let me point out that we have moved on to a slightly different topic. The tools that json_decode gives you is available in Go (it would be syntactically awkward, out of a necessity born of Go being statically typed). An example: http://play.golang.org/p/OvshdY1oVQ http://play.golang.org/p/OvshdY1oVQ However, I would write it as follows http://play.golang.org/p/pODFi9Jrve http://play.golang.org/p/pODFi9Jrve. This is merely a different way of doing the same thing. Now, to the topic that we are talking about is the claim that the latter is nicer. I was not comparing PHP and Go when I said that it was nicer (although I have some experience with PHP). I was drawing from my experience with working with JSON in statically typed languages. In particular, working with JSON in C++, Objective-C and Go. In all of these languages, the JSON libraries I used were essentially dynamically typed. I claimed merely that having the JSON library use reflection to deserialize into typed structures is nicer than using NSDictionary's various methods or maps in C++. In PHP, the syntactic overhead of walking dynamic structures is obviously much lower than the languages I was thinking about, so that criticism is blunted when referring to that language. But I still believe there is some advantage there. A large part of what I find nicer about the latter is indeed the same reason I prefer static typing to dynamic typing. It is impossible to mistype the latter (try changing the ".Foo" to ".Fo" and trying to run the snippet). Consider that doing the equivalent in PHP will simply return NULL (I think), as it is really just doing a dictionary lookup. I fully admit that this is a static versus dynamic thing, not about JSON in particular. As to the performance thing, I think you too easily discount the importance of low latency. But regardless, I was really comparing to Go's statically typed brethren. They essentially use hashtables for representing parsed JSON objects which is far less than ideal. Note that they don't employ the clever tricks that dynamic languages use. V8, for example, makes JS's objects (which are essentially hashtables) perform significantly better than a mere hashtable.
FuzzyDunlop 14y ago
I think it's nice that you can basically document the expected response, in the form of creating a type with a struct. In pseudo-code-ish: type FacebookUser struct { ProfileID int Name string .... } json.Unmarshal(response, FacebookUser) Compare it to the implementations that just give you a hash: json_decode($response); json.parse response Yeah, you can document it with comments, or visit the API documentation, but you can fix the code and let your comments go stale. You fix both your documentation and your implementation in one go in the first example. It's certainly why I find it more appealing, anyway. Makes me feel more secure in my code.