CODEWITHSUNDEEP
iosswiftxcodecocoa
SLN
SLN

Reputation: 5092

Apple Documentation and Xcode header file does not fully correspond

Environment:

XCode: Version 8.3.3 (8E3004b)

The Apple documents referred here is come from the XCode itself, not the online document

Description:

From Apple documents, the relationship of UITalbeViewController class with others are shown in the figure below. It inherits from 1 class and conforms to 7 protocols (you will find out that it conforms to 8 protocols from online documents [accessed at 18th June 2017]).

enter image description here

When I open the XCode header file by command click the UITalbeVIewController string, I got the following result (please see the figure below). It only shows out 2 protocols (UITalbeViewDelegate and UIBalbeVIewDataSource)

enter image description here

Question:

Why the header file does not show the other 5 protocols the UITableViewController conforms to?

Thanks for your time and help

Upvotes: 1

Views: 62

Answers (1)

deadbeef
deadbeef

Reputation: 5563

There are different reasons depending on the protocols.

Some protocols are adopted in an extension, and so do not appear listed in the class definition. Take the UIStateRestoring and NSExtensionRequestHandling protocols for example. You will find in the header of UIViewController that they are adopted by UIViewController in an extension (and so by inheritance are also adopted by UITableViewController).

Some have their adoption automatically generated by the compiler when importing Objective-C classes in Swift. As a result you will not see their adoption in the headers because the headers are just Objective-C headers rewritten in Swift. This is the case for Equatable and Hashable. In Objective-C all classes that inherit from NSObject have a isEqual(_:) method and a hash property and so automatically adopt the Equatable and Hashable protocols in Swift (but the protocols don't exist in Objective-C).

Some are used as markers by the compiler to implement the bridge between Swift and C or Objective-C. This is the case for the CVarArg protocol. You can see that this protocol is empty so could be adopted by any class or struct, but it's used to let the compiler know that classes that adopt it can be used safely with some very specific C APIs.

Upvotes: 3

Related Questions