On Jan 31, 2013, at 22:54 , Graham Cox <graham....@bigpond.com> wrote:
> For the errant CFTypes, I hit -valueForUndefinedKey: and > -setValue:forUndefinedKey:, overridden in this base class. This then checks > whether in fact the selector really is undefined, and if not, it forces the > value to be returned using -performSelector. It then passes off these CFTypes > to some conversion utilities that, for each type of interest, grabs all the > necessary values and puts them into a dictionary, and returns that. The > dictionary of course can be archived. On dearchiving, I simply reverse the > process, building new CFType objects from the dictionaries. This sounds potentially ugly, unless you left out some of the details. You can't simply check whether the selector is defined, since this will go terribly wrong if the property type is a genuine non-object that's not one of the scalars that KVC converts automatically. E.g. CGRect on the Mac. Second, you're kinda exposing the CFType'ed properties to *all* KVC use as objects, not just for archiving/unarchiving purposes. Don't be surprised if this bites you in the behind 6 months from now. > Those objects that can take advantage of this inherit from a simple base > class which exports one public class method, +archivableProperties, returning > a NSSet of keys. By doing this rather than using runtime introspection to > find all the properties allows objects to only specify those that they want > to auto-archive, and others can be ignored or handled as a special case if > needed. Then, this same base class implements default -initWithCoder and > encodeWithCoder: methods that iterate these keys using KVC to get and set the > property values. My idea was not that you'd use the runtime to *find* the properties. Rather, you'd get an array of them the way you originally intended, but check the property type before invoking the KVC methods, and in the CFType cases do the conversion without involving any KVC methods. That would avoid problems like the ones outlined above. _______________________________________________ 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
