I've been wondering if we should offer longer-lived adapters. If you want to _de_serialize 100 model objects, you're currently creating 100 adapters.
Instead, one could configure an adapter for one class once and reuse it.
Edit: I'm thinking about deserializing
What would the advantage be? Right now, adapter instances contain state related to the object being transformed (like the keys and transformers it wants to include), so that state would still have to be duplicated 100 times somewhere.
In the case of deserializing from JSON, isn't that state based on the class and unlikely to change between to deserializations?
(I'm just having performance concerns here)
Yes, but you also don't want that state kept around in memory after you're done deserializing stuff. I think it'd be hard to find the proper set up and teardown points.
@steipete I imagine you have thoughts here too.
yeah, definitely inspired by #112.
I could see keeping a could of adapters around in my API interaction layer for deserializing my most common model types, but I have not done any measurements, as you should.
The interface I'm proposing would look something like this
@interface MTLJSONAdapter : NSObject
@property (nonatomic, strong, readonly) Class modelClass;
+ (id)modelOfClass:(Class)modelClass fromJSONDictionary:(NSDictionary *)JSONDictionary error:(NSError **)error;
+ (NSDictionary *)JSONDictionaryFromModel:(MTLModel<MTLJSONSerializing> *)model error:(NSError **)error;
- (id)modelFromJSONDictionary:(NSDictionary *)JSONDictionary error:(NSError **)error;
- (NSDictionary *)JSONDictionaryFromModel:(MTLModel<MTLJSONSerializing> *)model error:(NSError **)error;
- (id)initWithJSONDictionary:(NSDictionary *)JSONDictionary modelClass:(Class)modelClass error:(NSError **)error __attribute__((unavailabe));
- (id)initWithModel:(MTLModel<MTLJSONSerializing> *)model __attribute__((unavailabe));
- (NSDictionary *)JSONDictionary __attribute__((unavailabe));
I imagine the class convenience methods to be the most popular hooks into serializing. I couldn't find any of the unavailable methods being used in Octokit* or my own code-base, so I don't expect migration to be painful.
* though I am on @Octokit/octokit.objc/92a428daf2d058ca92fc6b597e9af504434092af and couldn't pull because of the DDOS
The interface makes sense to me.
I guess saving one adapter instance per class isn't that big a deal, but that does mean we need to very carefully consider the footprint of each adapter (which might mean caching less data from the MTLModel).
Edit: added error parameters to the proposed interface