Option to change NSNull() return value to a real zero value

[dhoerl]

This is a hugely valuable project you created!

One huge issue I had in my last job was JSON nulls being returned by the web service. For instance, if someone had forgotten to set inventory, I'd get a null instead of zero. So I hacked up a category on NSNull so that I didn't have to test every single value before referencing it. The idea was that in most code, a zero would be just as useful as a null.

You can see others agree by the number of upvotes this answer got on SO: http://stackoverflow.com/a/16610117/1633251

What I am requesting is that you support an option that would result in no nulls being returned, with empty dictionaries, empty arrays, zero length strings, etc being returned instead.

If you want, I'll do the code and submit a pull request, but just tell me exactly how you want the option to work (and the actual string name if you care).

[LukeTangPL]

@dhoerl thank you very much. The NSNull Category which you post on stackoverflow in Objective-C is a masterpiece solution.
There are few way in SwiftyJSON to get NSNull object are var null: NSNull? and var object: AnyObject(better not use), other methods and properties that return the swift type in SwfityJSON are safe and reliable. such as:

let data: NSData = dataFromNetworking()
let json = JSON(data: data)
if let mayBeNull = json.null {
    //It's null
} else {
    //It's not null
}
if let string = json.string {
     //It's String or NSString
} {
     //It's not String or NSString
}

// If json is .String return the object as String, 
// if json is.Number or .Bool convert the object to String
// Otherwise return empty string
let iDontCare = json["iDontCare"].stringValue 

It's seem like NSNull Category.
If your have any idea, please let me know or submit a pull request.
Thanks.

[antoinerabanes]

Ideally if the value is null, the key should be removed.
in turn when you query the collection for this key it will return nil

[dhoerl]

I completely disagree on deleting the key. A 'null' JSON value is a valid return, and has meaning. I've experience with actual e-commerce JSON replies containing:

inventory : null // means it hasn't been entered yet
inventory: 50 // in stock at that level
inventory: -3 // yeah, got this! - the stupid e-commerce site sold 3 items before it realized it didn't have them in stock, so someone is on the phone now trying to calm a customer down (this really happened and crashed my app - I had coded inventory as a unsigned integer!)

[antoinerabanes]

Thats interesting insight and a good example of the complexity of integrating an API that returns null/NSNull.
However I would expect an integer back from the API and zero is a valid value to represent the stock when null is not because it is a different type and does not represent a number..

Sent from my iPhone

On 30 Jan 2015, at 17:00, David Hoerl notifications@github.com wrote:

I completely disagree on deleting the key. A 'null' JSON value is a valid return, and has meaning. I've experience with actual e-commerce JSON returns containing such:

inventory : null // means it hasn't been entered yet
inventory: 50 // in stock at that level
inventory: -3 // yeah, got this - the stupid e-commerce site sold 3 items before it realized it didn't have them in stock, so someone is on the phone now trying to calm a client down (yeah, this happened and crashed my app!)

—
Reply to this email directly or view it on GitHub.

[dhoerl]

All I can say is my comment reflects Apple's current thinking. Swift Optionals either have a value or don't. The value can be 0 or not (if its say an Int). Each of these three states (as stated in my earlier example) means something different. A framework like this one cannot afford (IMHO) to gloss over this and assume all users want "no value" to be mapped into "0" (or similar).

That said, after fussing with nil for weeks, I threw in the towel and created the NSNull category above, which gives you exactly what you want - two cases. Even so, I prefer this framework to do the proper thing, and let the user decide to map 3 states to 2 if desired.

[Nelyus]

@dhoerl You could something like this, without any change to JSON:

if let number = json.number?.integerValue ?? json.null?.integerValue {
  // do stuff
}

It'd be more explicit, which can be good.