Question

I need to have a class, which has all methods of NSArray, which behave the same way, but 2 methods are modified.

I want to override these 2 methods in my custom class:

1) countByEnumeratingWithState:objects:count:

2) objectAtIndex:

After hours of research I don’t see any reasonable way to do that, because:

• I don’t want to use category, because not all NSArray instances should have the modified behaviour. (Plus that throws warnings)

• I don’t want to re-write all initializers plus all arrayWith… methods + the primitive methods + implemented my own storage (because this functionality is already implemented in Cocoa, right? Why would I re-implement all the functionality of a class that is already there?)

• If I have my custom class inherit NSObject and use NSArray as storage in an ivar, then all NSArray’s methods are not available when programming in Xcode (even if I can forward them to the NSArray ivar)

• I had some success overwriting the method implementations on demand by using method_setImplementation(…), but still can’t figure out a way to have dynamically a class created at runtime, which then will have custom implementation of the 2 methods I mentioned.

Looking forward to your ideas! Thanks

Answer 1

Mantra: If something is hard (or seems like it requires more code than is necessary), it is likely that your design is counter to the design principals of the iOS / OS X frameworks. It may yield a better solution to revisit your design.

---

To answer the original question, if you want to subclass NSArray (or NSMutableArray), you need to implement the primitive methods, no more, no less.

The primitive methods are the methods declared in the @interface of the class itself. I.e.:

@interface NSArray : NSObject
- (NSUInteger)count;
- (id)objectAtIndex:(NSUInteger)index;
@end

And for NSMutableArray:

@interface NSMutableArray : NSArray
- (void)addObject:(id)anObject;
- (void)insertObject:(id)anObject atIndex:(NSUInteger)index;
- (void)removeLastObject;
- (void)removeObjectAtIndex:(NSUInteger)index;
- (void)replaceObjectAtIndex:(NSUInteger)index withObject:(id)anObject;
@end

If you subclass NSMutableArray and implement the above 7 methods (the two from NSArray, too), you will have an NSMutableArray subclass that is compatible — assuming your methods are correctly implemented — with all APIs that consume mutable arrays.

This is because of the way class clusters are designed. The public classes are abstract; are never directly instantiated. They provide a primitive interface that contains the class’s core functionality and then concrete implementations of all the other non-primtive API (save for the initializers, see below) that are implemented in terms of the primitives. Concrete, private, subclasses then override all the primitives and some of the non-primitives to provide optimal behaviors for specific configurations.

I want to have an NSArray instance for a library I’m working on and I
want to have it working transparently for the users of my library. Ie.
for them should be no difference between using a normal NSArray and
the modified class I’ll be providing. Ie. it’s a storage concern,
which the end users should not be concerned with and the interface
should remain the same as NSArray – therefore loosing all init methods
is not really an option at that point.

The initialization methods are not a part of the primitive interface to NSArray. You are adding a requirement above and beyond “make a class compatible with NSArray / NSMutableArray” as defined by the documentation. Nothing wrong with that, just pointing it out.

The reason why this is the case is because it is exceptionally rare to subclass the collection classes to provide the kind of business logic you describe. Collections are very generic in their behavior whereas such business logic that conditionalizes collection behavior would be done in a class that manages the overall model layer object graph.

If you really want to do this, provide an implementation of whatever init* methods you want, calling through to your wrapped generic instance as needed. There isn’t anything so special about the implementations of the initializers that you are going to lose much in doing so.

No need to implement all of them, either. Implement one or two and @throw a descriptive exception on the rest.

If you do decide to forward the ones that accept var-args, you can’t directly because there are no va_list accepting methods. Instead, you’ll want to convert the va_list of arguments into a language array (i.e. id[] foo = malloc(... * sizeof(id));) and pass it to initWithObjects:count:.

Some other comments:

• What you are doing [provide full NS*Array interface in a subclass] seems hard because it is not a common pattern and the framework designers saw no need to create a design to support it. Custom behaviors at the primitive collection levels are almost always better implemented at a higher level within the object graph. Almost always.

• method_setImplementation() and dynamic class creation is academically interesting, but pretty much never a solution. Obviously, mucking with the NSArray or NSMutableArray classes (or the concrete implementation classes) is going to blow up the rest of the frameworks that rely upon standard behavior. Beyond that it, it is a pattern of dynamic OO composition that is not really intended to be used in Objective-C; it’ll be a pain in the ass to maintain.