NSURLCOnnection no protocol?


When going through the Logger exercise I was wondering why i didnt have to say that my class Logger didnt conform to a NSURL Protocol of some sort. Of course Ch 25 explains that there isn’t as of the printing, a formal protocol defined for this class. So I just have to ask then, is how were the methods that we “overrode” in our logger.m file being called at all? would we have had problems if we our project wasnt a command line tool? thanks.

in the next edition of this maybe it would be good to explain how these methods were automatically being called when we didn’t say we were going to implement some of the methods that the NSURLConnection class understands.


Since Objective-C figures out the exact method to call at run-time, by looking at the selector in the method invocation, a method declaration does not have to be visible at the point of method invocation. This is one of the strengths (also the weakness) of Objective-C.

See “Dynamic Method Resolution” in Objective-C Runtime Programming Guide in Xcode’s documentation set.


i don’t think i understand you fully.

If the selector (i.e. a number that is assigned as described in the book) looks for a method and goes up the heirarchy tree to find that method then why do we have to declare that we are implementing a protocol at all by using the <> notation? Why couldn’t we just, by lots of memory and practice perhaps or by just looking at the docs, just know that we need to use a particular method that some “abstract class” like UITableView provides for us then just implement that in our “subclass”.???


The protocol declaration is needed to check for conformance at run time so that you don’t accidentally call a method that doesn’t exist:

- (void)barTo:(Foo *)foo
   if ([foo conformsToProtocol:@protocol (BarProtocol))
    // Talk to foo using the Bar protocol

<…> construct is for compile-time checking and for helping the humans reading the code:

@interface Foo: NSObject <Bar>

If you want to deepen your understanding, you should read the Objective-C manuals.


Why not have Xcode say something like “Well i see you are subclassing this UITableView “abstract class”. Here let me automatically stub out the required methods for you in your implementation file”. That way there are no conformance issues unless you accidentally change the method on accident or something for which the compiler should give you an error before run time.


That would be an excellent question for Apple. :slight_smile:

They do take developer feedback seriously. I recommend filing a Radar (bug/feature report) at bugreport.apple.com.

It’s the officially-recognized mechanism for us developers to provide feedback to Apple. It doesn’t have to be a bug - it can be a desired change in the APIs, documentation, etc.