Avoid additional static variables for related objects.

Question

When using related objects, the Objective-C runtime function is available, starting with iOS 4 and OSX 10.6, you must define a key for storing and retrieving the object at run time.

A typical use is to determine the key following

static char const * const ObjectTagKey = "ObjectTag"; 

and then use to store the object

 objc_setAssociatedObject(self, ObjectTagKey, newObjectTag, OBJC_ASSOCIATION_RETAIN_NONATOMIC); 

and get it

 objc_getAssociatedObject(self, ObjectTagKey); 

(example made by http://oleb.net/blog/2011/05/faking-ivars-in-objc-categories-with-associative-references/ )

Is there a cleaner way to define the associated key of an object that does not include declaring additional variables?

Answer 1

According to this blog entry by Erica Sadun (whose credits go to Gwynne Raskind ), there is.

objc_getAssociatedObject and objc_getAssociatedObject require a key to store the object. Such a key must be a constant void pointer. Therefore, in the end, we only need a fixed address, which remains constant over time.

It turns out that the @selector implementation provides only what we need, since it uses fixed addresses.

Therefore, we can simply get rid of the key declaration and simply use our property selection address.

So, if you bind at runtime a property like

 @property (nonatomic, retain) id anAssociatedObject; 

we can provide dynamic implementations for our getter / setter that look like

 - (void)setAnAssociatedObject:(id)newAssociatedObject { objc_setAssociatedObject(self, @selector(anAssociatedObject), newAssociatedObject, OBJC_ASSOCIATION_RETAIN_NONATOMIC); } - (id)anAssociatedObject { return objc_getAssociatedObject(self, @selector(anAssociatedObject)); } 

Very neat and definitely cleaner than defining an additional static variable key for each related object.

Is it safe?

Since it depends on the implementation, the legitimate question is: will it break easily? Citing Blog Entries

Apple may have to implement a completely new ABI for this to happen.

If we take these words as true, then they will be reasonably safe.

Answer 2

If you need access to the key from outside the scope of one method, a good template for this, which leads to more readable code, is to create a pointer that simply points to its own address on the stack. For example:

 static void const *MyAssocKey = &MyAssocKey; 

If you only need access from one method, you can simply use _cmd , which is guaranteed to be unique. For example:

 objc_setAssociatedObject(obj, _cmd, associatedObj, OBJC_ASSOCIATION_RETAIN_NONATOMIC); 

Answer 3

A small departure from @Gabriele Petronella's idea is to associate a dictionary with each object:

 //NSObject+ADDLAssociatedDictionary.h #import <Foundation/Foundation.h> @interface NSObject (ADDLAssociatedDictionary) - (void)addl_setAssociatedObject:(id)object forKey:(id<NSCopying>)key; - (id)addl_associatedObjectForKey:(id<NSCopying>)key; @end //NSObject+ADDLAssociatedDictionary.m #import <objc/runtime.h> @interface NSObject (ADDLAssociatedDictionaryInternal) - (NSMutableDictionary *)addl_associatedDictionary; @end @implementation NSObject (ADDLAssociatedDictionary) - (void)addl_setAssociatedObject:(id)object forKey:(id<NSCopying>)key { if (object) { self.addl_associatedDictionary[key] = object; } else { [self.addl_associatedDictionary removeObjectForKey:key]; } } - (id)addl_associatedObjectForKey:(id<NSCopying>)key { return self.addl_associatedDictionary[key]; } @end @implementation NSObject (ADDLAssociatedDictionaryInternal) const char addl_associatedDictionaryAssociatedObjectKey; - (NSMutableDictionary *)addl_associatedDictionaryPrimitive { return objc_getAssociatedObject(self, &addl_associatedDictionaryAssociatedObjectKey); } - (void)addl_setAssociatedDictionaryPrimitive:(NSMutableDictionary *)associatedDictionary { objc_setAssociatedObject(self, &addl_associatedDictionaryAssociatedObjectKey, associatedDictionary, OBJC_ASSOCIATION_RETAIN_NONATOMIC); } - (NSMutableDictionary *)addl_generateAssociatedDictionary { NSMutableDictionary *associatedDictionary = [[NSMutableDictionary alloc] init]; [self addl_setAssociatedDictionaryPrimitive:associatedDictionary]; return associatedDictionary; } - (NSMutableDictionary *)addl_associatedDictionary { NSMutableDictionary *res = nil; @synchronized(self) { if (!(res = [self addl_associatedDictionaryPrimitive])) { res = [self addl_generateAssociatedDictionary]; } } return res; } @end 

Then in our category on some subclass NSObject is produced

 //Derived+Additions.h #import "Derived.h" @interface Derived (Additions) @property (nonatomic) id anAssociatedObject; @end //Derived+Additions.m #import "NSObject+ADDLAssociatedDictionary.h" @implementation Derived (Additions) - (void)setAnAssociatedObject:(id)anAssociatedObject { [self addl_setAssociatedObject:anAssociatedObject forKey:NSStringFromSelector(@selector(anAssociatedObject))]; } - (id)anAssociatedObject { return [self addl_associatedObjectForKey:NSStringFromSelector(@selector(anAssociatedObject))]; } @end 

One of the advantages of the associated vocabulary approach as a whole is the added flexibility that arises from the ability to set objects for keys that are generated at runtime, not to mention a more pleasant syntax.

Advantage especially to use

 NSStringFromSelector(@selector(anAssociatedObject)) 

is that the NSStringFromSelector guaranteed to provide an NSString representation of the selector, which will always be an acceptable dictionary key. As a result, we do not need to worry (although I do not think this is a reasonable issue) about ABI changes.