Re: Understanding the docs. UIApplication for iOS
Re: Understanding the docs. UIApplication for iOS
- Subject: Re: Understanding the docs. UIApplication for iOS
- From: Alex Zavatone <email@hidden>
- Date: Tue, 04 Jun 2013 18:27:40 -0400
On Jun 4, 2013, at 1:44 PM, Fritz Anderson wrote:
> On 3 Jun 2013, at 7:37 PM, Alex Zavatone <email@hidden> 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.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden