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: Keary Suska <email@hidden>
- Date: Wed, 11 Jul 2012 17:54:13 -0600
On Jul 11, 2012, at 2:45 PM, Motti Shneor wrote:
> 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?
I would create a base class that implements -valueForUndefinedKey: and -setValue:forUndefinedKey: (per the doc links that another poster provided). These methods would simply get/set from the dictionary. The only thing that requires a little consideration is how you may choose to validate the key (if at all)--i.e. determine whether you want to throw an exception for unknown keys. You can throw by simply calling super's implementation. To validate you could keep an array of valid key names (somewhat fragile, as you need to keep it updated), or use runtime inspection functions (see: https://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/ObjCRuntimeGuide/Articles/ocrtPropertyIntrospection.html#//apple_ref/doc/uid/TP40008048-CH101-SW24). More cryptic but not fragile.
> 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 actually have a large project that uses pars of Core Data without an NSManagedObjectContext, as I have to use a specific RDBMS back-end. In fact, the context isn't needed unless you want storage and/or synchronization (relationship management, etc). I use a Managed Object Model to represent the data schema so I can have introspection, and subclass NSManagedObject. I also use the undefined-key technique for them, using the associated NSEntityDescription for key validation. I also have a system that allows properties to be added dynamically from SQL query results. Works like a charm.
> 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.
As was mentioned, you at least have to specify @dynamic, which really only promises the compiler that valid getter/setters will be available at runtime.
> 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.
This is all fine--just means that you have to create the classes and declare the properties to make the compiler happy.
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