HN Explorer

14 comments

[ 3.0 ms ] story [ 12.3 ms ] thread
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"
hxucaa
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)

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).
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?