Option to change NSNull() return value to a real zero value about swiftyjson HOT 6 CLOSED

@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.

from swiftyjson.

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

from swiftyjson.

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!)

from swiftyjson.

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 [email protected] 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.

from swiftyjson.

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.

from swiftyjson.

@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.

from swiftyjson.