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: Motti Shneor <email@hidden>
- Date: Wed, 11 Jul 2012 23:45:33 +0300
Wow, and thanks, everyone. BTW, what does "OP" stand for? (obviously, its me...)
Of what I read from everyone, and after examining the suggested code from Jens Alfke, I think I'm inclined to something simpler, hinted by Keary Suska. Could you spare a few more words on the "undefinedKey" override?
Obviously, I would use CoreData if I could. In fact, we use CoreData for the base model of our application. However, there is another "layer" higher than the CoreData model, that consists of intermediate data objects that serve as mediators between server messages and our "real" model objects in CoreData. The "Keys" or property-names are dictated by server definitions, and do not fully match those we have in our CoreData model.
We don't want these objects to be stored, and we don't want them to be dependent on some managedObjectContext (for threading reasons). Just simple, old-style, model objects.
I'd like to avoid dynamic auto-generation of methods at runtime. I can't see why this is needed --- ALL my getters and setters will look exactly the same.
We have dozens such "data classes", and I hate to copy-paste zillions of exactly-the-same implementations by hand. For every property (e.g. "firstName") I would need to to write
- (NSString *)firstName {
return [internalMutableDict valueForKey:firstName];
}
- (void) setFirstName :(NSString *)firstName {
[internalMutableDict setValue:firstName forKey:@"firstName"];
}
Isn't writing 1000 such implementations error-prone? call for automation of some kind?
The reason we insist on dot-notation for accessing these objects, is that the code which does this, is written in C++ or C style, using structs and dot notation. That code could compile with no change against C++ data objects (in Windows) or against my Propery-based data objects for Mac.
So... It's not that we're anti-CD, on the contrary.... only this is a big project with lot's of legacy shared code imposed on the system, to say nothing of legacy thinking and "shared thoughts" by management.
On 11 ביול 2012, at 17:25, Keary Suska wrote:
> 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 <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.
>
Motti Shneor,
---------------------------------------------------------
But they are useless ---
they can only provide answers!
(Pablo Picasso 1881-1973 about Computers).
_______________________________________________
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