5 ms·

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

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.
- lucian303 14y ago
  All good points. It would be interesting to see the different JSON implementations in different languages benchmarked. As far as static vs. dynamic, both have their pros and cons.

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.

lucian303 14y ago
All good points. It would be interesting to see the different JSON implementations in different languages benchmarked. As far as static vs. dynamic, both have their pros and cons.