The role of -supportsWeakPointers

Question

Apple have recently published Transitioning to ARC Release Notes, a document that explains ARC and tackles some of the issues of converting non-ARC code to ARC. In these notes, they mention the following:

If you you [sic] find that you must implement custom retain or release methods, then you must also implement the following method in your class:

-(BOOL)supportsWeakPointers { return NO; }

This method will prevent weak pointers from being formed to your objects. You are strongly encouraged to find a solution that doesn’t require implementing your own retain and release methods instead of doing this.

Consider this scenario:

1. Declare a class called MyClass and implement -supportsWeakPointers as returning NO. Tell Xcode to compile the corresponding implementation file with -fno-objc-arc. For good measure, declare the class as NS_AUTOMATED_REFCOUNT_WEAK_UNAVAILABLE and override -release and -retain.

2. In MainMenu.xib, place a top-level object of type MyClass.

3. In the application delegate, specify a weak IBOutlet property for an instance of MyClass:

   @property (weak) IBOutlet MyClass *myObject;
   

   and connect it to the corresponding object in the nib file.In this case, since the object is a top-level nib object and File’s Owner is of type NSApplication, that object is created with an extra reference count, which means it should stay alive until an explicit release. With ARC, this means calling CFRelease() since ARC forbids sending a release message.

My question is twofoldthreefold:

1. Why is -supportsWeakPointers an instance method instead of a class method? Is there any case where a class can have instances that differ with respect to allowing weak references?

2. -supportsWeakPointers is never sent to the MyClass instance created when the nib file is loaded; why? I’ve tested this by both placing an NSLog() inside of it and adding a symbolic breakpoint to Xcode. Also, I never get a

   cannot form weak reference to instance (0x???) of class MyClass
   

   message when I run the program.

3. The top-level nib object of type MyClass should never get deallocated during the program execution because my program never releases it. However, the corresponding weak outlet is nil after the nib file has been loaded; why? Changing the outlet property to strong results in the object being different from nil but this shouldn’t be necessary.Doesn’t really happen; sorry. I was testing a version that was assigning an fresh new object that wasn’t really used, so ARC correctly assigned nil to the property.

A sample project that reproduces this error is available here.

I’m using Xcode 4.2 with Apple LLVM Compiler 3.0 on a Mac OS X v10.7.2 box.

Answer 1

1. Consider the case of a class with both a "shared" or "default" instance and other instances (e.g. NSFileManager). Your shared instance likely has different weak pointer behavior from the other allocatable instances. There are times where different instances may want different weak pointer behavior. That having been said, if this is the case something's probably Not Quite Right.

   (Answer 1. was originally written by Chris Parker. I’m adding it to Joshua’s answer so that the accepted answer is complete.)

2. In your sample changing supportsWeakPointers to allowsWeakReference as defined in NSObject.h causes things to behave as one would expect. It's marked as NS_DEPRECATED but it doesn't look like there is an alternative in the SDK yet.

Answer 2

1. Consider the case of a class with both a "shared" or "default" instance and other instances (e.g. NSFileManager). Your shared instance likely has different weak pointer behavior from the other allocatable instances. There are times where different instances may want different weak pointer behavior. That having been said, if this is the case something's probably Not Quite Right.

2. Dunno. :)

3. Sounds like it might be a bug; I'd have to see a sample project to have a better idea of what's going on.