
Debunking the myths about parsing JSON in Swift - jtbrown
http://roadfiresoftware.com/2016/02/debunking-the-myths-about-parsing-json-in-swift/
======
seivan
Yes! 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
Wait... who told you I was writing that book? Just wait till you read next
week's article: "Debunking the myths about networking in Swift"

------
mpweiher
And 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
True. 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).

------
hxucaa
Swiftz
([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
Why is parsing JSON a problem in 2016 ?

~~~
krapp
It'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
Does Swift not have its own JSON parser ?

(IMA non-swift programmer)

~~~
tarentel
The Swift JSON parser is written in Objective-C. So kind of.

~~~
tomguthrie
Beginnings of a Swift one in the corelibs version of Foundation:
[https://github.com/apple/swift-corelibs-
foundation/blob/mast...](https://github.com/apple/swift-corelibs-
foundation/blob/master/Foundation/NSJSONSerialization.swift)

~~~
wrong_variable
How 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 ?

------
seanalltogether
doesn't look like it's protecting against nsnull values

~~~
jtbrown
If 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
The 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?

