Re: Your 'Class <Protocol>' Work

[<d dot ayers at inode dot at>]

>
> On 30 Sep 2004, at 5.25, David Ayers wrote:
>
>>> I apologize for not realizing this earlier; I kept thinking of when
>>> to issue the warning 'Class <Proto1, Proto2> may not respond to
>>> "bar"' and when to suppress it. A brief lecture of objc-act.c now
>>> reminded me that such a warning should _never_ be issued for
>>> receivers of type 'id' or 'Class', whether protocol-qualified or not.
>>
>> OK, now we either have a fundamental disagreement or a fundamental
>> misunderstanding.  If I send a message to a protocol qualified 'id'
>> which is not declared by the protocol, I expect a warning.  Why else
>> should I bother qualifying it?  Or what do you mean with "that such a
>> warning should _never_ be issued for receivers of type 'id' or
>> 'Class', _whether protocol-qualified or not_"?
>
> Hopefully this is just a misunderstanding, and not even a fundamental
> one. :-)
> When we say "warning", we are in fact talking about two different
> warnings:
>
>     (1)  'Foo' may not respond to 'bar'
>     (2)  'bar' not implemented by protocol(s)
>
> In the paragraph you quoted, I was saying that warning (1) should never
> be issued, but warning (2) should and is.  The distinction between these
> two warnings is crucial, since they have different semantics and impose
> different requirements on the implementation to produce them.  I seem to
> have completely forgotten about this distinction, until my epiphany.

Ahh, agreed.

>>
>> For the 'Class' case the situation a bit more hairy, due to the
>> semantics of instance methods in root classes.  What I'm trying to
>> achieve is that:
>>
>> Class <NSObject> clsP1;
>> Class <NSCoding> clsP2;
>>
>> [clsP1 retain];                 /* doesn't warn */
>
> Unless the NSObject protocol realy does provide +retain, then the
> compiler _should_ warn in this case.
>
>> [clsP2 encodeWithCoder: coder]; /* warns */
>>
>> Now if you are saying that you think it's OK, to warn in the +retain
>> case, (which is what I  understand from the second to last paragraph)
>> then, yes, we wouldn't need to mark root protocols at all.
>
> Exactly.
>
>>   But as the
>> correct retrieval of that prototype and the suppression of that
>> warning is _exactly_ what I'm trying to achieve, I have written the
>> code to   mark
>> those protocols and to test that mark when searching for protocols.
>
> Ok, I guess we have a disagreement after all. :-(  As you said above,
> the very reason you'd want to protocol-qualify 'id' or 'Class' in the
> first place is so that the compiler could warn you if you're invoking a
> method _not_ listed in those protocols.  The machinery you're trying to
> put in place will defeat this mechanism; why would you want to do
> this?
>
> If you do not want to see a warning in this case, you can use either (1)
> an unadorned 'Class' or (2) a concrete ObjC class (e.g., 'NSObject') as
> the receiver.  In both cases, the compiler will look at instance
> methods
> as a last resort.
>
>> This is especially important when the prototypes start mismatching
>> which
>> was part of the original trigger for me to do this at all.
>
> I don't understand this last sentence at all. :-(  Can you show an
> example of when "prototypes start mismatching"?  Perhaps this will help
> me understand your motivation a bit better.

@protocol <CommonMethodNames1>
- (const char *)name;
- (void)set;
- (int)compare:(id)obj;
- (int) host
@end

@protocol <CommonMethodNames2>
- (NSString *)name;
- (NSSet *)set;
- (BOOL)compare:(id)obj;
- (NSString *)host
@end

But you do have a point...  My major concern is code generation wrt
prototype selection.  So maybe we could compromise by:
1. emitting the diagnostics
2. fallback to searching for instance methods of protocol qualified
'Class' independent of whether it was declared by a root class to select a
prototype before falling back to the global table.

> As you suggested, I think I will whip up a separate patch that
> incorporates
> (and probably modifies) your testcases to show you what I mean.
>

Well, I was actually refering to the comptypes issue, but be my guest :-)

Cheers,
David