Open Radar

 
Summary:
NSObject protocol is right now a monolithic grouping of a number of methods important for general use of objects. I propose splitting some of these methods into new protocols which NSObject conforms to, in order to better-document the requirements of methods that are currently using e.g. id. As a point of comparison, look at the recent change of the type of keys in NSMutableDictionary to id<NSCopying> from id; this change allows the compiler to check the conformance in many cases and is additionally excellent documentation for the developer on what a dictionary requires of its keys.

Proposed protocols follow:

- NSSending:
	- -performSelector:
	- -performSelector:withObject:
	- -performSelector:withObject:withObject:

- NSDescribing:
	- -description
	- -debugDescription (which should perhaps be made optional, with the debugger falling back to -description automatically, instead of putting the onus for this on the implementor)

- NSEquating:
	- -isEqual:

- NSHashing:
	- -hash

- NSIntrospection (this one could probably be broken down further):
	- -class
	- -superclass
	- -isMemberOfClass:
	- -isKindOfClass:
	- -respondsToSelector:
	- -conformsToProtocol:

…and so on.

The specific intended use case is adding type information to e.g. -isEqual: to allow the developer to build type-safe algorithms without resorting to id or the equally vague id<NSObject>. Thus my RXEqual() function (which simply returns (a == b) || [a isEqual:b]) can declare that its arguments require -isEqual:, and the compiler has that much more information available to it.

Steps to Reproduce:
Look at NSObject (the protocol).

Expected Results:
I expected it to be split into multiple logical sub-protocols.

Actual Results:
It was instead a monolithic protocol conflating various concerns.

Regression:
N/A

Notes:
N/A