4 ms·
Debunking the myths about parsing JSON in Swift
- seivan 11y agoYes! Someone finally said it. The worst are the operators. You don't need these libraries and their lack of tests. Noticed this might be an ad about a book... Parsing JSON in Swift. The bubble is real. What developer would buy this? What's next, a book about NSURLSession?
- jtbrown 11y agoWait... who told you I was writing that book? Just wait till you read next week's article: "Debunking the myths about networking in Swift"
- hxucaa 11y agoSwiftz (https://github.com/typelift/Swiftz https://github.com/typelift/Swiftz) offers well tested implementation of operator definitions and constructs from functional language. It takes inspiration from Scalaz and Haskell. If I were to write a library using wacky operators, I'd at least use well defined and maintained definitions.
- wrong_variable 11y agoWhy is parsing JSON a problem in 2016 ?
- krapp 11y agoIt's not if you use a language that comes with its own JSON parser. I don't know why anyone would bother writing their own, though.
- wrong_variable 11y agoDoes Swift not have its own JSON parser ? (IMA non-swift programmer)
- tarentel 11y agoThe Swift JSON parser is written in Objective-C. So kind of.
- tomguthrie 11y agoBeginnings of a Swift one in the corelibs version of Foundation: https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSJSONSerialization.swift https://github.com/apple/swift-corelibs-foundation/blob/mast...
- wrong_variable 11y agoHow sad. Apple has 80 billion dollar in cash - and are unable to pay someone to write a standard JSON parser - for a language they want other developer to adopt. Do they expect unpaid developers to make one for them ?
- mpweiher 11y agoAnd here's your regularly scheduled announcement that the actual JSON parsing is done by the library call NSJSONSerialization.JSONObjectWithData(...) in line 3 of the code. The rest is just getting the parsed data out of already parsed nested dictionaries and arrays in a way that makes the type checker happy. Calling that "parsing" is probably the biggest myth of them all (though agreed about all the other myths).
- efaref 11y agoTrue. Although the Android JsonReader class does force you to write your own parser (it is itself merely a lexer). This is really inelegant. What I'd really like is a way to write my POD types as normal: class Foo { int bar; String baz; ArrayList<String> blah; ArrayList<Xyz> xyzs; } class Xyz { String name; int value; } And then just write this to parse it all. ... Parser<Foo> p = new Parser<Foo>(); Foo f; try { f = gp.parse(input); } catch (JsonParseException e) { ... } I'd be willing to accept having to annotate some of the fields, (but other than that, this should be possible to do).
- seanalltogether 11y agodoesn't look like it's protecting against nsnull values
- jtbrown 11y agoIf you're talking about either the bad (pyramid of doom) code in Myth #1 - or the good code there, then it is indeed protecting against null values in the JSON. When you try to cast with `as? String`, it returns nil when there's a null value in the JSON and the code in the `if` block is skipped (and the `else` block is executed if one exists).
- seanalltogether 11y agoThe point is that neither of them are good. Nulls should be expected in json objects, so why write the parsing inside a conditional that will fail when one is encountered?