4 ms·
Agreed server side swift will be awesome. My only complaint is that JSON parsing is kind of a major pain. Libraries like Argo and SwiftyJSON help, but code can
by supster 11y ago
Agreed server side swift will be awesome. My only complaint is that JSON parsing is kind of a major pain. Libraries like Argo and SwiftyJSON help, but code can still get really verbose.
- tcdent 11y agoIsn't that a problem with most typed languages? You're bringing in untyped data, so native types need to be spelled-out somewhere. There's a line somewhere between excessive verbosity and dumb trust (like the YAML snafu). I haven't seen great syntax yet, though.
- supster 11y agoAgreed, it would be cool if we could specify untyped zones within a function e.g. @untyped func parse(json: AnyObject) -> String? { /* code here is not type checked, if returned value is not type String then value will become nil */ }
- rjbwork 11y agoNewtonsoft.Json with dynamics is really good at it in the .NET world. I usually use actual typed objects, but the DLR has enabled some cool stuff concerning dynamic input type things.
- bribri 11y agoArgo is great and applicative functors are a great way of parsing in a type safe way
- Tloewald 11y agoI think the problem is JSON. Because JSON is tied so strongly to Javascript it tends to be very ugly in any other language. I think we need a simplified (and more concise) alternative to JSON that more closely matches the way languages that aren't Javascript work. E.g. most JSON APIs don't send arrays of primitive types (numbers, strings) around, but allowing for them makes implementing JSON nicely in non-JS languages decidedly uglier. JSON's quoting of symbols is just inefficient (it's not any other language's fault that Javascript's set of reserved words is bizarre, and in any case no-one should be "eval"ing JSON these days.)
- TazeTSchnitzel 11y agoJSON isn't ugly in languages that aren't JavaScript. It's ugly in languages which aren't dynamically typed and have poor type systems.
- jp_rider 11y agoI ported Haskell's [Aeson](http://hackage.haskell.org/package/aeson-0.10.0.0/docs/Data-Aeson.html http://hackage.haskell.org/package/aeson-0.10.0.0/docs/Data-...) library to [Swift](https://github.com/PKAuth/SwiftAeson https://github.com/PKAuth/SwiftAeson). You might find it helpful with verbosity and better type checking. Note that there is some hackery to satisfy Swift's type checker (and its type inference usually doesn't help too much).