Feature Request: Call backs for Deserializing about jsonkit HOT 7 OPEN

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.

from jsonkit.

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

from jsonkit.

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; }

from jsonkit.

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.

from jsonkit.

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;

from jsonkit.

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.

from jsonkit.

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

from jsonkit.