JSON serializer and tests. #291
Conversation
| @@ -97,7 +97,26 @@ public class NSJSONSerialization : NSObject { | |||
| /* Generate JSON data from a Foundation object. If the object will not produce valid JSON then an exception will be thrown. Setting the NSJSONWritingPrettyPrinted option will generate JSON with whitespace designed to make the output more readable. If that option is not set, the most compact possible JSON will be generated. If an error occurs, the error parameter will be set and the return value will be nil. The resulting data is a encoded in UTF-8. | |||
| */ | |||
| public class func dataWithJSONObject(obj: AnyObject, options opt: NSJSONWritingOptions) throws -> NSData { | |||
| NSUnimplemented() | |||
| guard obj is NSArray || obj is NSDictionary else { | |||
There was a problem hiding this comment.
Isn't this going to fail for e.g. [String] or [String:Any]? Because those are not automatically bridged to NSArray and NSDictionary on Linux, so unless things have changed, I don't think this will work on Linux.
There was a problem hiding this comment.
You are right, this is a consequence of the current bridging situation. There is also the fact that the documentation of NSJSONSerialization says that the top-level objects must be NSArray or NSDictionary - so perhaps the documentation needs updating as well.
There was a problem hiding this comment.
Note that the signature is for AnyObject not Any as well...
There was a problem hiding this comment.
You're right, but the parsing code uses native Swift types like [Any] and [String: Any], which I think is the right way to do it. I think here you should detect native Swift containers as well, so that it works properly both on OS X and Linux.
There was a problem hiding this comment.
The 'NSDictionary' or 'NSArray' language is just a reflection of the JSON spec, which says that the top level must be an 'Object' or 'Array'. We can use a Swift dictionary or array here.
There was a problem hiding this comment.
@parkera That's how I read it too. Now, if @ianpartridge does want to detect the native Swift containers as well, what would you recommend is the right approach? I wrote my own JSON parser Jay, where I had to opt in for ugly (almost) exhaustive checking of all Array/Dictionary types, because of the lack of automatic bridging on Linux. Is there a better way to do it that I missed?
There was a problem hiding this comment.
I think a recursive descent of the input and checking all types along the way is the most reasonable way to do this for now. There's a lot of libraries out there that are exploring different avenues for parsing JSON in a type-safe way, but I haven't seen a clear winner among the approaches yet.
There was a problem hiding this comment.
Right, that makes sense to tell a String from a Int, but iterating through all possible [String: String], [String: Int], [String: Double`, ... is less than ideal I think. I'm fine with using this for detecting different JSON-compatible types, but is it really the best way to detect different Array and Dictionary types?
|
Hi @parkera - could you review this please? Happy to make improvements if needed, but I'm hoping this is a decent starting point. |
|
@swift-ci please test |
|
Let's go ahead and merge this, then continue to improve it incrementally. |
|
Thanks for your hard work on this! |
Revert "[test] Workaround an issue with createDirectory on Linux"
This implements
NSJSONSerialization'sdataWithJSONObject(_:options:), providing a JSON serializer and associated tests. It is RFC 7159 compliant, I hope.There is another pull request implementing this API, which has been unmerged for some time. I believe this approach is superior, because
Feedback wanted please!