Feature Request: Call backs for Deserializing

[jasongregori]

I would try to do this myself but the level of sophistication in JSONKit is far beyond me. Perhaps this wouldn't even be possible without really slowing JSONKit down?

Anyways, there are two problems I have that could be fixed by something like this.

1. Our company's JSON passes dates as strings in the format "/Date(1305758490476)/" (This is something that .net does). It would be great if I could have a callback, see this is in the date format, and return an NSDate.
2. I hate NSNulls! I know that sometimes you really need to keep nulls in your collections, however, usually NSNulls cause a lot more work. For example, I get a url for an image. I have to double check that it's not an NSNull before creating an NSURL from the string. What a pain! The other option I'm left with is going through all the objects manually and getting rid of NSNulls. So I would like to get a callback and return nil so the NSNull won't be added in.

Anyways, thoughts?

[johnezang]

Lots of thoughts, and it's something that I've been thinking about. I added callbacks to the serialization process, but that was relatively straightforward. But so far I haven't been able to come up with a clean and elegant way of adding callbacks to the deserialization process.

So, it's been on my radar, but I have yet to come up with something that I'm happy with. Unfortunately, I wouldn't expect this feature to get added any time soon. I'd much rather do it right then do it half-assed.

[jasongregori]

Totally makes sense. Just wanted to make sure it was somewhere on the long list (even if only the wish list :). Thanks for reading my message. Oh yeah when I saw the callbacks for serialization I got so psyched thinking there must be matching deserialization ones :)

On May 18, 2011, at 10:34 PM, johnezangreply@reply.github.com wrote:

Lots of thoughts, and it's something that I've been thinking about. I added callbacks to the serialization process, but that was relatively straightforward. But so far I haven't been able to come up with a clean and elegant way of adding callbacks to the deserialization process.

So, it's been on my radar, but I have yet to come up with something that I'm happy with. Unfortunately, I wouldn't expect this feature to get added any time soon. I'd much rather do it right then do it half-assed.

Reply to this email directly or view it on GitHub:
#25 (comment)

[FunkeeMonk]

RE: the 2nd point regarding NSNull's, add the one-line i've included below inside _JKDictionaryAddObject() inside JSONKit.m after NSCParameterAssert() and you'll have the functionality you want for the NSDictionary category.

Caveat emptor! Be careful what you wish for. As johnezang explained in another issue, returning NSNull is a feature, not a bug. There is a very good reason why JSONKit is returning NSNull, as NSNull and nil means different things, representing different situations which you may have to cater for in your app.

static void _JKDictionaryAddObject(JKDictionary *dictionary, NSUInteger keyHash, id key, id object) {
  NSCParameterAssert((dictionary != NULL) && (key != NULL) && (object != NULL) && (dictionary->count < dictionary->capacity) && (dictionary->entry != NULL));
  if (object == [NSNull null]) { CFRelease(key); CFRelease(object); return; }

[jasongregori]

Thank you @FunkeeMonk. Your comment also helps me understand some of the things going on in JSONKit.

I would also want the arrays to work like this. Do you think this would work correctly? It looks right to me but I'd like a second (or third) opinion.

static void _JKArrayInsertObjectAtIndex(JKArray *array, id newObject, NSUInteger objectIndex) {
  NSCParameterAssert((array != NULL) && (array->objects != NULL) && (array->count <= array->capacity) && (objectIndex <= array->count) && (newObject != NULL));
  if(newObject == [NSNull null] || !((array != NULL) && (array->objects != NULL) && (objectIndex <= array->count) && (newObject != NULL))) { [newObject autorelease]; return; }

I've added object == [NSNull null] to the beginning of the third line.

[jasongregori]

That last one didn't work. This did though. In the function static void *jk_parse_array(JKParseState *parseState) I changed the state in the switch statement for nulls to this:

case JKTokenTypeNull:
    if(JK_EXPECT_F((arrayState & JKParseAcceptValue)          == 0))    { parseState->errorIsPrev = 1; jk_error(parseState, @"Unexpected value.");              stopParsing = 1; break; }
    if(JK_EXPECT_F((object = jk_object_for_token(parseState)) == NULL)) {                              jk_error(parseState, @"Internal error: Object == NULL"); stopParsing = 1; break; } else { arrayState = JKParseAcceptCommaOrEnd; }
    break;

[jparise]

Adding rich deserialization callbacks could avoid the cost of creating intermediate dictionary objects when the desired result is an application-specific object instance. That might be more complicated than what's being proposed here, however, as it would extend to custom-deserializing container types instead of just simple values.

[jasongregori]

Yeah that could get pretty complicated. This library is already super complex and optimized. I got those darn nulls out so I'm happy :).