mikeash.com pyblog/friday-qa-2013-10-25-nsobject-the-class-and-the-protocol.html comments

Crispin Bennett - 2013-11-21 20:53:00

Thu, 21 Nov 2013 20:53:00 GMT

@Gwynne Aha. So nothing really to puzzle over there.

Gwynne Raskind - 2013-11-21 20:49:42

Thu, 21 Nov 2013 20:49:42 GMT

@Crispin Bennett: Neither; it's because most of those protocols were added to the headers before the convention of adding <NSObject> to protocols came around. In short, it's backwards compatibility; changing it now would break source compatibility and possibly binary compatibility as well.

Crispin Bennett - 2013-11-21 20:21:32

Thu, 21 Nov 2013 20:21:32 GMT

Why do some of Apple's protocols (eg. NSFastEnumeration) *not* inherit from <NSObject>?

Two possibilities I've seen canvassed are (1) that Apple anticipates some protocols may be used with classes not themselves using NSObject as a root class, or (2) to differentiate (semantically) between protocols specifying whole application roles (eg. delegate protocols) and those specifying only individual behaviours (eg. being enumerable).

Mark Aufflick - 2013-11-04 20:09:37

Mon, 04 Nov 2013 20:09:37 GMT

@Arl one answer is that it's a question of declaring intent. Your class doesn't care if someone passes in an object that has any particular inheritance structure, all you care about is whether it can respond to a particular set of messages.

Mark Aufflick - 2013-11-04 20:04:38

Mon, 04 Nov 2013 20:04:38 GMT

Just thought I'd point out that MAProxy doesn't adopt the NSObject protocol ;)

https://github.com/mikeash/MAFuture/blob/master/MAProxy.h

Ari Weinstein - 2013-10-29 17:35:47

Tue, 29 Oct 2013 17:35:47 GMT

This is a silly question, but I must ask:

Wouldn't this have the same effect, assuming NSObject is the root class?



NSObject<MyProtocol> *obj;

In fact, due to the protocol and class namespaces being different, you could even do:



typedef NSObject<MyProtocol> MyProtocol;

MyProtocol *obj;

Obviously this is a bad idea for readability and probably other reasons, but it does work - you can even send messages the "MyProtocol" class, though obviously they will end up being sent to NSObject itself.

I've actually used this method when implementing a UIViewController class-cluster type thing, where I couldn't cleanly implement a common superclass because some of the classes had to be subclasses of other UIViewControllers. For example, one is a subclass of QLPreviewController and yet another is a subclass of PKAddPassesViewController.

So I implemented the class cluster as a category on UIViewController itself, created a protocol for the "subclasses" implement, and then typedef'd UIViewController<DCPushPreviewController> to DCPushPreviewController, and because UIViewController itself adopts DCPushPreviewController, everything works out perfectly, including sending messages to the "DCPushPreviewController" class.

I'd be thrilled to hear if there was a cleaner way to do this.

BergQuester - 2013-10-29 04:28:31

Tue, 29 Oct 2013 04:28:31 GMT

Looking at the GNUStep implementation of NSObject and NSProxy (I was able to find the source of Apple's NSObject on their open source page, but not NSProxy), over half of the methods are exact or near exact duplicates with minor variations (preprocessor macro differences, variable names). The rest either isProxy forward the method onto the 'real' object (e.g. performSelector:, isKindOfClass:, respondsToSelector:, etc).

Granted, this is GNUStep and not Apple's code and it's not that much code. But assuming Apple shares this amount of duplication between the two, it seems odd to me not have a OneTrueRootClass.

The reason NSProxy doesn't subclass the NSObject class is because, as Mike points out, there's a lot of extra baggage that comes with the class itself. But I'm still failing to see any significant impact in moving just the NSObject protocol methods to a OneTrueRootClass, aside from historical considerations.

BergQuester - 2013-10-28 20:44:51

Mon, 28 Oct 2013 20:44:51 GMT

KenThomases, inheriting the superclass's (in our case a root class) instance methods is a major reason to subclass. Every instance method declared in the NSObject protocol, except debugDescription, is required. Whether or not these methods were moved to a OneTrueRootClass, NSProxy is required to respond to these methods.

Maybe there's more overhead in consolidating these shared methods than I am aware of, or perhaps the implementation details are so radically different for each of these methods that the code is entirely different. On the surface though, things like retain, release, autorelease, self, perform selector, etc would seem to have a near universal implementation between NSObject and NSProxy.

KenThomases - 2013-10-27 05:42:09

Sun, 27 Oct 2013 05:42:09 GMT

BergQuester, root classes are special in that class objects also respond to the instance methods of the root class. Since we want the class objects of subclasses of NSObject to respond to much of the same goodness of NSObject, we'd have to lift that goodness into the root class if NSObject were not the root class. Then that goodness would also be in NSProxy and defeat the purpose of making NSProxy minimal.

Also, you'd still want the NSObject protocol for the purpose of inheriting into other protocols, as Mike explained. So you wouldn't gain anything by having a One True Root Class.

Bleyddyn - 2013-10-25 16:26:25

Fri, 25 Oct 2013 16:26:25 GMT

I always inherit from the NSObject protocol because I've yet to run across a case where leaving it out was necessary and I almost always end up wanting to quiet compiler warnings if I don't.

Anyone have any examples where it might be a good idea to leave it off?

BergQuester - 2013-10-25 15:52:05

Fri, 25 Oct 2013 15:52:05 GMT

The mechanics of this make sense. However, why have a protocol to enforce this rather than taking all of the methods in the NSObject protocol and creating the One True Root Class that NSObject, NSProxy, et. al. can inherit from?

Is the choice between a new root class and a protocol just a historical detail?