Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unsupported Classes #47

Open
a2 opened this issue Sep 2, 2011 · 5 comments
Open

Unsupported Classes #47

a2 opened this issue Sep 2, 2011 · 5 comments

Comments

@a2
Copy link

a2 commented Sep 2, 2011

Instead of (or in addition to) using blocks to serialize unsupported class types, perhaps a protocol could be used. Classes would implement this protocol in order to be serialized naturally.

@soffes
Copy link
Contributor

soffes commented Sep 2, 2011

I love that idea. I think it would be neat if it was something like

- (id)JSONValue;

That just returned one of the supported classes, since most of the time you would want to return a dictionary or an array or something.

@a2
Copy link
Author

a2 commented Sep 4, 2011

How about something like:

@protocol JKCoding <NSObject>

- (id) JSONRepresentation;
- (id) initWithJSONRepresentation: (id);

@end

Remember that if we implement something like this, the JSON will just contain an array, dictionary, string, or number representation of this object. What we need to do is somehow store the class hierarchy "chain" like Apple does in its .plists so that we know what class we have when we're unarchiving/unserializing. The reason we store the class hierarchy is so that if the first class is unavailable we can default to the next, and so on.

Perhaps something like:

If MyArray is an NSMutableArray subclass, and -[MyArray JSONRepresentation] yields @"JSON VALUE", we could encode it like this:

["JSON_VALUE", "MyArray", "NSMutableArray", "NSArray", "NSObject"].

@johnezang
Copy link
Owner

Is there any reason why the current block / delegate pattern in place can't be used to implement this?

I don't necessarily disagree with the request. It's more a matter of finding the balance between which features should be included in the core and providing primitives that allows the end-user to easily extend the core to better fit their particular needs.

I'm of the opinion that it's far more important to provide high quality general purpose primitives that would allow a feature like this to be implemented than necessarily providing the feature itself. What's a must have feature to use is bloat to someone else. :) I think something like this would be better done in a Cookbook.md like file that would provide patterns that others would likely find useful while at the same time serving as documentation on how to make use of the provided primitives to accomplish something.

Thoughts?

@ghost ghost assigned johnezang Oct 21, 2011
@a2
Copy link
Author

a2 commented Oct 21, 2011

No, you're right. You have to develop for 80% of your target user base. The feature I'm describing would be for encoding entire objects, which is something that could go in a Cookbook file.

Cheers

@teerapap
Copy link

teerapap commented Feb 9, 2012

I agree that block/delegate pattern is useful enough. However, in case there are many objects of unsupported classes, there would have many temporary NSDictionary or NSArray objects along the serialization.

Is there a way to deal with this situation?

How about an selector of the delegate that serialize the object by itself to a buffer or NSMutableData which JSONKit provided.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants