Re: Understanding the docs. UIApplication for iOS

  • Alex Zavatone wrote:

    > I think you might have some confusion about what a protocol is in Obj-C, which might be making it hard to frame your question in terms that make sense to the rest of us.

    It's not what a protocol is that's confusing (a neatly packaged set of methods geared for a specific purpose), ...
     
    And yet, that's really not a good definition of what a protocol is. That's closer to a category.

    Really the best description of a protocol is the definition of the word protocol itself. It's a sort of contract that defines the way one object can assume it's able to interact with another. It's not a set of methods but of messages. So back to your first post:

    "It's not listed that the UIApplication class conforms to the UIApplicationDelegate, ..."

    Right. Because UIApplication *does not* conform to UIApplicationDelegate. It's a client of that protocol.
  • On Jun 3, 2013, at 7:42 PM, gweston wrote:

    > Alex Zavatone wrote:
    >
    >>> I think you might have some confusion about what a protocol is in Obj-C, which might be making it hard to frame your question in terms that make sense to the rest of us.
    >>
    >> It's not what a protocol is that's confusing (a neatly packaged set of methods geared for a specific purpose), ...
    >
    > And yet, that's really not a good definition of what a protocol is. That's closer to a category.

    OK, how about what I said + "for the purpose of establishing a formal mechanism for classes to talk to each other"?

    > Really the best description of a protocol is the definition of the word protocol itself. It's a sort of contract that defines the way one object can assume it's able to interact with another. It's not a set of methods but of messages. So back to your first post:
    >
    > "It's not listed that the UIApplication class conforms to the UIApplicationDelegate, ..."
    >
    > Right. Because UIApplication *does not* conform to UIApplicationDelegate. It's a client of that protocol.
    > _______________________________________________
    > Do not post admin requests to the list. They will be ignored.
    > Xcode-users mailing list      (<Xcode-users...>)
    > Help/Unsubscribe/Update your Subscription:
    > https://lists.apple.com/mailman/options/xcode-users/<zav...>
    >
    > This email sent to <zav...>
  • On 3 Jun 2013, at 7:37 PM, Alex Zavatone <zav...> wrote:

    > On Jun 3, 2013, at 7:42 PM, gweston wrote:
    >
    >> Alex Zavatone wrote:
    >>
    >>>> I think you might have some confusion about what a protocol is in Obj-C, which might be making it hard to frame your question in terms that make sense to the rest of us.
    >>>
    >>> It's not what a protocol is that's confusing (a neatly packaged set of methods geared for a specific purpose), ...
    >>
    >> And yet, that's really not a good definition of what a protocol is. That's closer to a category.
    >
    > OK, how about what I said + "for the purpose of establishing a formal mechanism for classes to talk to each other"?

    I think people are taking care to be precise. Your initial impression was off by a ways, and what you're saying now is still a bit off-center.

    _All_ method declarations in class interfaces establish a formal mechanism for objects to communicate with them.

    What makes a protocol different is that a class can make a promise to implement a certain API; and a parameter (or whatever) can demand that API without having to specify a particular class. The compiler enforces the promise and the compatibility as best it can.

    As for UIApplication and <UIApplicationDelegate>, I'm not sure what you're driving at. The documentation doesn't hint that UIApplication conforms to that protocol. The @interface directive for UIApplication doesn't say it conforms to <UIApplicationDelegate>. That should be enough. It's not fair to expect a class reference to specify what the class isn't.

    UIApplication _uses_ an object conforming to <UIApplicationDelegate>, but that no more makes it a delegate than having an NSString property makes it a string.

    And you're right, Apple has never provided a documentation system as good as the third-party browsers. (The class browser in Xcode 3 came close.) If you can navigate the class tree, the "complies through" chains become very clear.

    — F

    --
    Fritz Anderson
    Xcode 4 Unleashed: 4.5 supplement for free!
    http://www.informit.com/store/xcode-4-unleashed-9780672333279
  • On Jun 4, 2013, at 10:44 AM, Fritz Anderson <fritza...> wrote:

    > What makes a protocol different is that a class can make a promise to implement a certain API; and a parameter (or whatever) can demand that API without having to specify a particular class. The compiler enforces the promise and the compatibility as best it can.

    It’s exactly like an ‘interface’ in Java (and a lot of other languages have identical concepts.) It lets a class inherit an API but not implementation. It’s a less complex alternative to multiple inheritance — you can inherit from multiple things, but only one of them can have an implementation, so you don’t get the awful problems you find in C++ when multiple base classes implement the same method.

    If you aren’t familiar with Java interfaces, then think of a protocol as a special kind of class that doesn’t implement any of its methods, so you have to implement/override them all. But in exchange a class gets to inherit from multiple protocols in addition to a base class.

    —Jens
  • On Jun 4, 2013, at 1:44 PM, Fritz Anderson wrote:

    > On 3 Jun 2013, at 7:37 PM, Alex Zavatone <zav...> wrote:
    >
    >> On Jun 3, 2013, at 7:42 PM, gweston wrote:
    >>
    >>> Alex Zavatone wrote:
    >>>
    >>>>> I think you might have some confusion about what a protocol is in Obj-C, which might be making it hard to frame your question in terms that make sense to the rest of us.
    >>>>
    >>>> It's not what a protocol is that's confusing (a neatly packaged set of methods geared for a specific purpose), ...
    >>>
    >>> And yet, that's really not a good definition of what a protocol is. That's closer to a category.
    >>
    >> OK, how about what I said + "for the purpose of establishing a formal mechanism for classes to talk to each other"?
    >
    > I think people are taking care to be precise. Your initial impression was off by a ways, and what you're saying now is still a bit off-center.
    >
    > _All_ method declarations in class interfaces establish a formal mechanism for objects to communicate with them.
    >
    > What makes a protocol different is that a class can make a promise to implement a certain API; and a parameter (or whatever) can demand that API without having to specify a particular class. The compiler enforces the promise and the compatibility as best it can.

    I think I'm starting to see the details here, but certainly haven't realized them and their implications yet.

    If I'm to read in to this, you're saying that there is a promise that these will be implemented - and you're implying that it doesn't matter what implements it, whatever implements it is decoupled from the protocol, but all those protocol methods must be implemented and at runtime, Cocoa can move in (lame term, I know), connect or hook up which ever object it determines needs to be there.

    Correct-ish?

    > As for UIApplication and <UIApplicationDelegate>, I'm not sure what you're driving at. The documentation doesn't hint that UIApplication conforms to that protocol. The @interface directive for UIApplication doesn't say it conforms to <UIApplicationDelegate>. That should be enough. It's not fair to expect a class reference to specify what the class isn't.
    >
    > UIApplication _uses_ an object conforming to <UIApplicationDelegate>, but that no more makes it a delegate than having an NSString property makes it a string.

    Yeah, that's where I had a bit of a disconnect.  In situations like that, it's obvious that I tried to get information on how things work that I can hint to the new user.  It's best not doing that in this case.

    > And you're right, Apple has never provided a documentation system as good as the third-party browsers. (The class browser in Xcode 3 came close.) If you can navigate the class tree, the "complies through" chains become very clear.
    >

    Xcode 3.1.3 was pretty great.  I have to admit, I loved working in that environment.
  • On Jun 4, 2013, at 3:27 PM, Alex Zavatone <zav...> wrote:

    > If I'm to read in to this, you're saying that there is a promise that these will be implemented - and you're implying that it doesn't matter what implements it, whatever implements it is decoupled from the protocol, but all those protocol methods must be implemented and at runtime, Cocoa can move in (lame term, I know), connect or hook up which ever object it determines needs to be there.

    Kind of, but you’re making it seem like a different thing from the way classes normally work, when it isn’t really.

    A protocol is like a class, except that
    - It can’t implement any methods, only define messages in its API. In other words, it’s purely abstract.
    - Classes can inherit from (implement) one or more protocols in addition to a single base class.
    - A class that implements a protocol has to implement all the methods of that protocol (except those declared as @optional.)

    That’s about it for the differences. Except for little nits like you refer to a protocol as @protocol(Foo) instead of [Foo class] for some reason, and you test for inheritance with -conformsToProtocol: instead of -isKindOfClass:.

    (In languages with multiple inheritance like C++ or Common LISP there isn’t any difference between these entities, they’re just different types of classes with or without abstract methods. But in practice multiple inheritance gets really messy to use, so the protocol/interface mechanism was invented as a way to get many of the benefits without all the complexity.)

    So mostly you can think of a protocol as a special kind of class. UIApplicationDelegate is an abstract base class that app delegates have to inherit from. It just has the convenience that, since it’s a protocol, your class can inherit from a real base class (like UIResponder) as well, and inherit implementation from it.

    —Jens
previous month june 2013 next month
MTWTFSS
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
Go to today