3

Xcode generated this header file based on a template: 

// this file is XYZAppDelegate.h  
#import <UIKit/UIKit.h>
@interface XYZAppDelegate : UIResponder <UIApplicationDelegate>
....
@end

For the compiler to figure-out what UIApplicationDelegate is, this is how it works?
(1) the entire UIKit framework (UIKit.h) has been imported.
(2) UIApplication.h is one, of many, header files specified in UIKit.h.
(3) the UIApplicationDelegate protocol is then specified in UIApplication.h.

Just for the sake of my understanding, could i write a:
@interface XYZAppDelegate:UIResponder <direct-reference-to-protocol>

maybe, something like:
@interface XYZAppDelegate:UIResponder <UIKit.UIApplication.UIApplicationDelegate>

davewp
  • 243
  • 2
  • 11
  • No, you can't do what you are asking. Why do you want to? What is wrong with the way it is? – rmaddy Dec 15 '13 at 20:55
  • I'm trying to reduce the amount of unnecessary information in my source files. As well as, just figuring-out how obj-c and Xcode works. – davewp Dec 15 '13 at 20:59
  • What unnecessary information is in your source files? At the moment it has just the necessary info. – rmaddy Dec 15 '13 at 21:01
  • Wouldn't I need over 100 unwanted function declarations just to reference the function declarations in the UIApplicationDelegate protocol? – davewp Dec 15 '13 at 21:08
  • But that is all hidden away in the header file. Your source file simply has a few needed `#import` statements. There is no real need to worry about the fact that some declaration you don't happen to use in the .m file came along for the ride. Let the compiler worry about that. You don't need to add or see the unwanted declarations. – rmaddy Dec 15 '13 at 21:14
  • In this case, it's pointless. You're not going to get very far at all without importing UIKit. It's already in your precompiled header anyway, so you don't even need to import it here. In other cases, it is perfectly valid to just import a specific file with `#import ` – Mark Adams Dec 16 '13 at 07:26
  • So, just for the sake of my understanding, I could import all of the frameworks into my pre-compiled header, and not be risking name clashes (or anything else)? – davewp Dec 16 '13 at 15:24

2 Answers2

2

You maybe want to check this out What is the difference between #import and #include in Objective-C?
Sure, you can 

#import <UIKit/UIApplication.h> 
#import <UIKit/UIResponder.h>

instead of 

#import <UIKit/UIKit.h>

However, i can see some disadvantages this way. What if Apple will move UIApplicationDelegate protocol declaration to another header upon time? What if you'll need in some of your files 10 UIKit classes? Would you write

#import <UIKit/UIView.h>
#import <UIKit/UIScrollView.h>
#import <UIKit/UIButton.h>
...
#import <UIKit/header_over_9kth.h>

However, you can try optimizing your imports and post compiling time reports here. It would be interesting if you'll achieve more performance with such optimisations

Community
  • 1
  • 1
Petro Korienev
  • 4,007
  • 6
  • 34
  • 43
  • I don't think there will be any performance improvements, since UIKit is already loaded into memory. – Aaron Brager Dec 15 '13 at 21:59
  • It's difficult question. I agree with you that there will be no performance improvements but i think the truth is hidden inside llvm & clang implementations. – Petro Korienev Dec 15 '13 at 22:39
2

To specify a protocol on a class it needs to be known by the compiler. The one and only way to do that is by specifying

@protocol MyProtocol
...
@end

This is also the case for classes, categories, anything.

The compiler, like any C compiler, processes file by file. It can and will not remember anything it saw between runs. This means, to be able to know what MyProtocol is, the compiler must be provided with the protocol definition like above in the very same file.

Because it would be very annoying to always specify things a million times, the C people have figured out decades ago, that it would be great if there would be preprocessor directives that insert a specific file at the place where the directive is. This is when #include was born.

#import is basically the same as #include, only that it also checks if the file has been included before and doesn't do it multiple times as #include would do. Both just take the file and pretend the whole content of that file would be at the place of the directive - nothing more.

As neither C nor Objective-C have framework level namespacing, every symbol that is known to the compiler can and must be simply used by specifying its name. Things like the . syntax for namespace that you may know from Java (like System.out.println()) or other programming languages don't exist.

felinira
  • 1,644
  • 15
  • 21
  • Actually, this is the better answer. That the declarations "must be in the same file" is the nuts/bolts of what's going on. I totally understand this now. thanks. – davewp Dec 17 '13 at 13:53