Vincent Gable’s Blog

Here’s a category of NSObject that can simplify a dealloc method. It adds the method, setEveryObjCObjectPropertyToNil, that sets every property of the receiver to nil. (Properties that are readonly or not an Objective-C object are ignored.) This frees the underlying object, if the property is declared copy or retain; and it does no harm if it was declared assign.

If every ivar (member variable) in your object has a property declared for it, then your dealloc method can often be replaced by this macro, or it’s two-line expansion:

#define PROPERTY_ONLY_OBJECT_DEALLOC \
- (void) dealloc { \
   [self setEveryObjCObjectPropertyToNil]; \
   [super dealloc]; \
}


Limitations

Pointers

Any pointers (eg char*) will not be set to NULL; this includes pointers to an Objective-C object (eg NSError** outError). Of course NSObject* obj will be set to nil since it is considered an Objective-C object, even though it is written as if it were a pointer.

It is easy to build on setEveryObjCObjectPropertyToNil and have something that sets pointers to NULL as well. But I felt it was too risky. Sending a message to nil is valid, but dereferencing a NULL pointer is a “bus error” crash. [nil release]; does no harm, but free(NULL); is bad news. A settable @property that takes a raw pointer is a hybrid Objective-C, and “old”-C creature — I’ve never seen such a thing, so I’m wary of assuming that feeding it a NULL would be valid. Plus, opening the door to pointers means dealing with handles (pointers-to-pointers) and their ilk.

ivars

Any ivars (member variables) with no settable @property declared on them will not be freed. You can inspect your own ivars like you can @propertys (example), but it would not be safe to automatically release them. Some of them might be weak-links, meaning the object they point to was not sent a retain message. Weak-links are not terribly rare, for example objects always have a weak link to their delegate.

The Code

You will still need to download the source to get helper functions like SetterNameFromPropertyName() for this to actually run, but this should give you an idea of how it works:


@implementation NSObject(CleanUpProperties)
- (void) setEveryObjCObjectPropertyToNil;
{
   unsigned int i, propertyCount = 0;
   objc_property_t *propertyList = class_copyPropertyList([self class], &propertyCount);
   if(propertyList){
      for(i = 0; i < propertyCount; i++){
         const char *propertyAttrs = property_getAttributes(propertyList[i]);
         if(PropertyIsObjCObject(propertyAttrs) && PropertyIsSettable(propertyAttrs)) {
            NSString *setterName = SetterNameFromAttributes(propertyAttrs);
            if(!setterName)
               setterName = SetterNameFromPropertyName(property_getName(propertyList[i]));
            [self performSelector:NSSelectorFromString(setterName) withObject:nil];
         }
      }
      free(propertyList);
   }
}
@end


Download The Code

And please let me know how it works for you. I’ve started using setEveryObjCObjectPropertyToNil even if I only have one @property, because it means I’ll never forget to free one.

Warning (Update 2009-05-29)

Uli Kusterer gives a good reason not to use this code,

Don’t Use Accessors in Constructors or Destructors

This may sound a bit odd, but there is a reason to this madness. Constructors (i.e. -init methods in ObjC) and destructors (i.e. -dealloc or -finalize) are special methods: They are called before your object has fully been initialized, or may be called after it has already been partially torn down.

If someone subclasses your class, your object is still an object of that subclass. So, by the time your -dealloc method is called, the subclass has already been asked to do its -dealloc, and most of the instance variables are gone. If you now call an accessor, and that accessor does anything more than change the instance variable (e.g. send out notifications to interested parties), it might pass a pointer to its half-destructed zombie self to those other objects, or make decisions based on half-valid object state. The same applies to the constructor, but of course in reverse.

Now, some people that accessors should not be doing anything but change instance variables, but that is utter nonsense. If that was all they’re supposed to do, we wouldn’t need them. Accessors are supposed to maintain encapsulation. They’re supposed to insulate you from the internal details of how a particular object does its work, so you can easily revise the object to work in a completely different way, without anyone on the outside noticing. If an accessor could only change an instance variable, you would have very limited means to change this internal implementation.

Moreover, I don’t think Apple would have introduced Key-Value-Coding and Key-Value-Observing if they didn’t agree at least partially that it’s fine to do a bunch of things in response to an accessor being used to mutate an object.

Update 2009-11-29

I’m amused at the prevalent “Apple knows best” attitude. Bindings, garbage collection, NSOperationQueue, and so many other things, Apple has gotten wrong and burned me in the process. I always trust my own evaluation over their recommendations.

—Mike Ash, Using Accessors in Init and Dealloc