Comments on: Class Extensions Explained

By: Nimrod

Nimrod — Fri, 15 Oct 2010 17:41:38 +0000

Great explanation. Thanks! This was very useful.

By: Dan

Dan — Fri, 05 Feb 2010 19:50:56 +0000

Darn. And thanks, but darn. I guess it’s plan B then: put all of my source code into one file. (j/k)

By: bbum

bbum — Fri, 05 Feb 2010 15:59:02 +0000

Dan — it is a good idea, but won’t work in practice. A class extension doesn’t declare the superclass and, thus, the compiler wouldn’t know about any inherited methods when it only saw the extension. It would also be incompatible with the 32 bit Mac OS X runtime in that the compiler has to see the instance variables of the super classes to be able to correctly layout ivars in the current class.

However, if you are willing to be “limited” to 64 bit and iPhone OS only (the only downside being lack of compatibility with the simulator), you can achieve what you want today using a combination of synthesized properties (that also synthesize ivars) and class extensions at the top of the .m to hold private properties and method declarations.

By: Dan

Dan — Fri, 05 Feb 2010 15:03:50 +0000

One of the very few things I dislike about Obj-C over other languages is the lingering need for header files (unlike Java, Python, etc.). But I’ve recently thought of an approach that, while not making them unnecessary, at least would reduce the back-and-forth between editing the two files, somewhat. However, I’m wondering if it will lead to unexpected problems.
The approach would be to put the only the class extension @interface in the header, declaring the methods and properties I want other classes to be aware of (thus “public”), while the interface containing the ivars and private methods would be in the implementation (.m) file. Is this plan “so crazy, it just might work!”, or a “bag of hurt ™”? Secondly, if it would work, would Clang’s static analyzer have trouble understanding it? Would code sense?
Lastly, I’d like to thank you for your profuse and generous contributions to the Cocoa development community’s knowledge base! It really is appreciated by so many of us.

By: Jonathan Mitchell

Jonathan Mitchell — Wed, 09 Dec 2009 15:48:52 +0000

Class extensions come galloping to the rescue when you turn on GCC_WARN_UNDECLARED_SELECTOR.
All those callback message selectors that you forgot to declare anywhere can be decanted into the extension without polluting the public interface.

By: Michael James

Michael James — Thu, 05 Nov 2009 22:40:33 +0000

Found this out through experimentation:

To access the readwrite property from subclasses, re-declare the property as readwrite in your subclass’s class extension and use “@dynamic propertyName” in the @implementation section. Seems to work.

Sorry for the typos.

By: Kyle Sluder

Kyle Sluder — Sun, 13 Sep 2009 03:25:25 +0000

Ahruman, are you sure about accessing synthesized ivars being a bug? I thought the bug was that one couldn’t get at the synthesized ivar and therefore had to implement -dealloc by calling setters. Now we can use self->ivar notation.

By: bbum's weblog-o-mat » Blog Archive » Class Extensions Explained interface

bbum's weblog-o-mat » Blog Archive » Class Extensions Explained interface — Sat, 12 Sep 2009 12:17:45 +0000

[...] Read the original post: bbum's weblog-o-mat » Blog Archive » Class Extensions Explained [...]

By: Drew McCormack

Drew McCormack — Sat, 12 Sep 2009 09:07:33 +0000

One thing I have wanted to do at various times is expose a immutable property, but back it with a mutable ivar. So I wanted this in the public interface

@property (readonly) NSArray *array;

and in the class extension I wanted to use this

@property (readwrite) NSMutableArray *array;

This doesn’t seem to be allowed by the compiler. Of course, you can get around it by simply renaming the ivar to mutableArray or something, but it seemed like something that should be possible (ie upcasting of a class in a property.

By: Tweets that mention bbum’s weblog-o-mat » Blog Archive » Class Extensions Explained -- Topsy.com

Fri, 11 Sep 2009 22:03:51 +0000

[...] This post was mentioned on Twitter by Mike Clark, JivaDeVoe and Matthew Tonkin. Mike Clark said: @bbum's "Class Extensions Explained" is another must-read for ObjC programmers: http://bit.ly/778Gg [...]