On Jul 11, 2012, at 8:03 AM, Dave DeLong wrote:
> 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.
Sorry, I misread. Since the OP doesn't care about pre-declaring all the
properties, then the most elegant answer is, "use Core Data." Why reinvent the
wheel? All the functionality is already there, and then some.
OP: If for whatever reason you feel that you need to reinvent the wheel, or you
need your own backing store that isn't CD-friendly, it seems much simpler to me
to just override the "undefinedKey" methods.
Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"
> On 2012-07-11, at 6:46 AM, Keary Suska <cocoa-...@esoteritech.com> 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.
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
