31–40 of 55 posts
For anyone wondering why this is necessary, as some others in this thread have mentioned, the standard go way to deserialize json is to pass a pointer to a struct, and the system will "fill" it with the json. There is no easy way to sort of "parse" json piece by piece, which is what this library provides
For anyone wondering why this is necessary, as some others in this thread have mentioned, the standard go way to deserialize json is to pass a pointer to a struct, and the system will "fill" it with the json. There is no easy way to sort of "parse" json piece by piece, which is what this library provides
I sometimes have trouble understanding Go. It kind of seems to retain a lot of the bad parts of C in terms of developer-friendliness, while still being relatively slower than C and garbage-collected.
The name is a little "unfortunate", give that there's a JSON editor for Mac OS X with the exact same name.
I would stray away from making the library name too similar in phonetic sound to the data it's meant to process. There was already enough confusion in an office I worked at with a non-developer whose name was "Jason"
I would stray away from making the library name too similar in phonetic sound to the data it's meant to process. There was already enough confusion in an office I worked at with a non-developer whose name was "Jason"
We had a developer named Jason, fortunately he mainly did XML.
Out of context, you sound insane.
For anyone wondering why this is necessary, as some others in this thread have mentioned, the standard go way to deserialize json is to pass a pointer to a struct, and the system will "fill" it with the json. There is no easy way to sort of "parse" json piece by piece, which is what this library provides
Earlier quoted context omitted.
Thanks for your feedback. I created the library simply because it just fits my use cases better. I have used encoding/json quite a lot, and for instance, I think golang's strict types makes it inconvenient to dig through arbitrary maps in a quick way. That's what the Get-method in Jason is trying to solve. Similar to how bitly/go-simplejson does it, but with some fine tuning.
Speaking of the .Get method, wouldn't returning an error alongside the value instead of just the default object be more idiomatic?
For anyone wondering why this is necessary, as some others in this thread have mentioned, the standard go way to deserialize json is to pass a pointer to a struct, and the system will "fill" it with the json. There is no easy way to sort of "parse" json piece by piece, which is what this library provides
>For anyone wondering why this is necessary, as some others in this thread have mentioned, the standard go way to deserialize json is to pass a pointer to a struct I sometimes have trouble understanding Go. It kind of seems to retain a lot of the bad parts of C in terms of developer-friendliness, while still being relatively slower than C and garbage-collected.
Earlier quoted context omitted.
I pronounce JSON as "jay-sawn" to avoid the confusion with the name. I've heard "jiss-on" and various other mutations used as well.
American? The North American accent pronounces "Python" similarly, as "py-THAWN" instead of "PIE-thn".
For anyone wondering why this is necessary, as some others in this thread have mentioned, the standard go way to deserialize json is to pass a pointer to a struct, and the system will "fill" it with the json. There is no easy way to sort of "parse" json piece by piece, which is what this library provides
>For anyone wondering why this is necessary, as some others in this thread have mentioned, the standard go way to deserialize json is to pass a pointer to a struct I sometimes have trouble understanding Go. It kind of seems to retain a lot of the bad parts of C in terms of developer-friendliness, while still being relatively slower than C and garbage-collected.