Re: How to implement an object whose properties are really dictionary entries.
Re: How to implement an object whose properties are really dictionary entries.
- Subject: Re: How to implement an object whose properties are really dictionary entries.
- From: Dave DeLong <email@hidden>
- Date: Wed, 11 Jul 2012 07:03:35 -0700
It sounds like the OP is looking for a model object that uses an NSMutableDictionary as the backing store for its properties, as opposed to individual ivars. You can do this.
You declare all your properties, and you declare a single NSMutableDictionary ivar. All of the properties should be implemented as @dynamic in the .m file.
Since the properties are dynamic, the compiler will not generate implementations for them. You'll have to do that yourself at runtime. Fortunately, if you know what you're doing, that's not too hard.
You'll have to override +resolveInstanceMethod: to figure out what the user is trying to do: get or set. You'll use the selector passed in to derive the key under which you're storing the data in the dictionary. With this information, you construct a block of the appropriate signature, capturing whatever information you need, and turn it into an IMP using imp_implementationWithBlock(). You can then add that method to the class using class_addMethod().
So yes, this is totally possible. However, it seems like it'll be a lot of work if all you're doing is trying to save yourself from implementing a few setters and getters.
Dave
Sent from Jane
On 2012-07-11, at 6:46 AM, Keary Suska <email@hidden> wrote:
> On Jul 11, 2012, at 6:34 AM, Motti Shneor wrote:
>
>> Hi. I guess many have already stumped into this one, but my wildest phrasing attempts in web-searches didn't yield.
>>
>> I'd like to have a "data" object, similar to (but much simpler than) CoreData entity, which only exports a bunch of properties. Something like
>>
>> @interface MSPersonalData :NSObject
>> {
>> }
>> -(id) initWithData:(NSDictionary*)initialData;
>> -(id) init;
>> @property (nonatomic, retain) NSString* firstName;
>> @property (nonatomic, retain) NSString* lastName;
>> @property (nonatomic, retain) NSDate* birthDate;
>> @property (nonatomic, retain) NSNumber* salary;
>> @end
>>
>> I'd like this object to have NO ivars, and NO property implementations, not even synthesized. Instead I'd like the object to either inherit from NSMutableDictionary or own a single NSMutableDictionary ivar, and I'd like any access to my object to be transparently translated to internal dictionary valueForKey: and setValue:forKey:.
>>
>> Simply put, I'd like code like this:
>>
>> MSPersonalData *myDataObject = ;[MSPersonalData alloc] init];
>> myDataObject.firstName = @"Motti";
>>
>> to actually perform
>>
>> [self setValue:@"Motti" forKey: @"firstName"]; // if MSPersonalData inherits NSMutableDictionary
>> or
>> [internalDictionary setValue:@"Motti" forKey: @"firstName"]; // if MSPersonalData owns NSMutableDictionary.
>>
>> Such object can be very useful for UI binding, and as self-documented API for a sub-system. Instead of declaring a set of static keys as string, just behave as if there were iVars per each key of the object. I think CoreData NSManagedObjects do this, in their "primitive" implementation.
>>
>> I tried several schemes for implementation, but all became cumbersome, and I had to do much trickery, and in the end it looked ugly. I strongly feel there must be a simple and elegant way to do this. To have a mutable dictionary react to the "syntactic sugar" of dot notation.
>>
>> Is there a good, general solution for this?
>
>
> What is hampering you, it seems to me, is your requirement to use dot syntax. At least, to use dot syntax and not get a bunch of compiler warnings. Even Core Data still requires you to declare properties to avoid compiler warnings, which is a good sign that what you are after is not "cleanly" possible.
>
> HTH,
>
> Keary Suska
> Esoteritech, Inc.
> "Demystifying technology for your home or business"
>
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden