Inheritance and class methods

[Alexmipego]

Hi,

Today I came across a situation where I needed to subclass
CPShadowView to provide some extra functionality for my project. To
initialize the view I used the class method shadowViewEnclosingView:
which automatically configures everything and replaces target view by
itself on the superview. Peachy.

Later I realized my methods weren't being called and I tracked the
reason to the CPShadowView shadowViewEnclosingView's method where it
has the following code:

var shadowView = [[CPShadowView alloc] initWithFrame:[aView frame]];

I tested replacing the CPShadowView in that snippet to simply "self"
and it work flawlessly as I'm used to do on my iOS projects. However,
after trying to build a test case (on a native cocoa app) I found out
that my trivial tests with NSString, NSDictionary and such would
always say something about "you need to implement method X on your
concrete class" which is, I assume, a way to force you to reimplement
everything.

So I ask, wouldn't it be better for code reusage sake, to simply use
self instead of the class name when initializing an object from a
class method?

[Francisco Tolmasky]

Short answer, yes, this appears to be a bug, shadow view should be using "self" (please file it, or better, just changing it and issue a pull request and we should be able to take it quickly). However, if you're curious to know why your tests failed with NSString and NSDictionary...

So as it turns out NSString and NSDictionary are actually the least trivial cases you could use. Along with NSArray, NSSet, etc., these are all class clusters ( http://developer.apple.com/library/mac/#documentation/General/Conceptual/DevPedia-CocoaCore/ClassCluster.html ). Normally if you had something like NSAbstractArray, you'd know full well not to try to instantiate it and it would expect errors such as the ones you saw. However, class clusters are abstract classes that pretend to be concrete classes, but are actually implemented by secret subclasses.  For example, try the following in Cocoa:

NSLog(@"%@", [[[NSArray alloc] init] class]);

You'd expect to see "NSArray". But instead you'll see something like "__NSArrayI". The reason for this is that all these subclasses exist purely for performance reasons, nothing that concerns you at the programmer level. The Cocoa implementors are just clever enough to do something special if you have, say, an empty array, or a sparse array, or a dense array, etc. There is a great article about this if you're interested on doing further reading here: http://ridiculousfish.com/blog/posts/array.html .

So, in order to do a trivial test case your best bet is to just use something outside of Foundation where things are less "tricky".