Introducing PMJSON, a Swift Library for JSON Encoding/decoding(engineering.postmates.com)
engineering.postmates.com
Introducing PMJSON, a Swift Library for JSON Encoding/decoding
http://engineering.postmates.com/Introducing-PMJSON/
1 comments
Any advantage over others JSON libraries?
Depends on which library you're comparing it to. Most Swift JSON libraries actually just wrap `NSJSONSerialization`, which means they depend on Foundation and you end up with a mess of objects that need to be explicitly type-checked. The ones that convert the results into an enum also are doing a lot of extra work; they decode the JSON into objects, and then process those objects into a completely different set of values, and then you work with those values.
There are some other libraries out there that implement their own pure-Swift JSON decoder/encoder without depending on Foundation. I haven't looked much at them (and the ones I've seen all came out after I started PMJSON anyway), so I don't know how good they are, or what features they offer.
Some of the benefits in general of PMJSON:
* The core library doesn't depend on Foundation at all. There's two files that use Foundation, to convert to/from plist-compatible objects, but you can remove those files and the rest of the project will compile just fine.
* It parses the JSON natively, so it uses the nice strongly-typed enum representation without having to go through another intermediate representation first.
* Also, by not using NSJSONSerialization, there's no chance of getting Obj-C exceptions (which Swift can't handle).
* The parser is split into separate parsing and decoding stages, so you can take the output of the parsing stage and deserialize directly to your own data structure if you wish, completely bypassing the JSON enum representation. The parser also works with any sequence of UnicodeScalar values, so you can deserialize from arbitrary representations of the JSON text. Similarly, you could pipe your own sequence of JSONEvents into the decoder, so you can experiment with different parser implementations if you want. I'm considering experimenting with a specialized parser for String inputs that yields substrings of the input whenever possible instead of building new strings.
* Really good errors. Everything produces the best errors it can, including full paths for nested JSON values (e.g. "response.elements[1].name: expected string, found null") without having to build up a path on every access, meaning you only pay for the nice errors if an error occurs.
* It's liberally licensed, offered under both MIT and Apache License, Version 2.0.
There are some other libraries out there that implement their own pure-Swift JSON decoder/encoder without depending on Foundation. I haven't looked much at them (and the ones I've seen all came out after I started PMJSON anyway), so I don't know how good they are, or what features they offer.
Some of the benefits in general of PMJSON:
* The core library doesn't depend on Foundation at all. There's two files that use Foundation, to convert to/from plist-compatible objects, but you can remove those files and the rest of the project will compile just fine.
* It parses the JSON natively, so it uses the nice strongly-typed enum representation without having to go through another intermediate representation first.
* Also, by not using NSJSONSerialization, there's no chance of getting Obj-C exceptions (which Swift can't handle).
* The parser is split into separate parsing and decoding stages, so you can take the output of the parsing stage and deserialize directly to your own data structure if you wish, completely bypassing the JSON enum representation. The parser also works with any sequence of UnicodeScalar values, so you can deserialize from arbitrary representations of the JSON text. Similarly, you could pipe your own sequence of JSONEvents into the decoder, so you can experiment with different parser implementations if you want. I'm considering experimenting with a specialized parser for String inputs that yields substrings of the input whenever possible instead of building new strings.
* Really good errors. Everything produces the best errors it can, including full paths for nested JSON values (e.g. "response.elements[1].name: expected string, found null") without having to build up a path on every access, meaning you only pay for the nice errors if an error occurs.
* It's liberally licensed, offered under both MIT and Apache License, Version 2.0.