views:

113

answers:

2

I develop CHDataStructures, a library of Cocoa data structures to supplement those in Foundation. It includes a fair number of classes (stacks, queues, and dequeues) that share common implementation details, so it makes sense to design them with a common parent class which I treat as abstract (Objective-C doesn't natively enforce this concept). For example, CHAbstractCircularBufferCollection encapsulates nearly all the logic for structures that utilize a circular buffer under the covers. Its child classes inherit the core behaviors, and conform to the appropriate protocol so only the methods that pertain to that protocol are added. (So a queue doesn't expose stack methods, etc.)

This has been working just fine, and correctness and coverage are verifiable via unit tests. However, the downside to the current approach is that each concrete subclass has a #import to include the header for the abstract parent class (see this header and implementation) — this means I have to export the parent class headers so client code will compile. It would be ideal if there is a way to use @class in the header rather than #import, so that calling code doesn't have to know or care about the abstract parent class. (It would also simplify and marginally shrink the size of the framework.) However, when I try this:

// CHCircularBufferQueue.h
#import "CHQueue.h"
@class CHAbstractCircularBufferCollection;

@interface CHCircularBufferQueue : CHAbstractCircularBufferCollection <CHQueue>

@end

I get this error, even if I #import CHAbstractCircularBufferCollection.h in the .m file:

Cannot find interface declaration for 'CHAbstractCircularBufferCollection', superclass of 'CHCircularBufferQueue'

I want the compiler to know about the parent class I'm extending, but not require clients to. Is there a way to accomplish what I want to do, and eliminate irrelevant headers from my distribution?

PS - This framework arose mostly from academic curiosity, but I'm considering making changes to make it more like Foundation collections by using class clusters and private subclasses. That would also solve this problem, but I'm curious whether there is a feasible way to do what I'm asking.

+2  A: 

If you want to inherit a class, the superclass's @interface (hence the whole superclass hierarchy) must be known so that the ivar offsets of the subclass can be calculated.

KennyTM
Accepted since you were first with the right answer: the parent class is the only class header that **must** be imported. Interestingly enough, the Modern Runtime could do without the header, but @bbum says "we haven't gone there" — it's the way it is because of legacy runtime baggage for the most part.
Quinn Taylor
+2  A: 

You have to #import the .h file for the superclass. As KennyTM points out, this is so the compiler can calculate ivar offsets for the object struct. You can see this in any Cocoa header file. For example, if you open NSArray.h, the very first non-comment line is:

#import <Foundation/NSObject.h>

This holds true for every other class in Cocoa.

Dave DeLong