Re: Your 'Class <Protocol>' Work

[David Ayers <d dot ayers at inode dot at>]

Ziemowit Laski wrote:
> On 30 Sep 2004, at 16.31, d.ayers@inode.at wrote:
> 
> 
>>@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
> 
> 
> Oooh, that is pretty hairy. :-( But I don't think your proposal (or 
> mine, for that matter) deals with this issue, does it? I'm assuming
> that you're worrying about constructions like:
> 
>    id <CommonMethodNames1, CommonMethodNames2> obj;
>    Class <CommonMethodNames1, CommonMethodNames2> cls;
>      :
>    ... [obj name] ...
>    ... [cls name] ...
> 

Umm, no. But it was late when I replied and I was rather terse.  The
case can not be handled.  It would entail associating multiple
implementations for a selector for any given class and defining a new
construct to indicate at the call site, which protocol to use.

I just want to insure that when a protocol qualified 'Class' type is
declared (usually because we can't use static typing), that the
prototype of the instance methods take precedence before the global
method lists.  I'm still not sure whether this should only be done for
protocols adopted by root classes and go through the trouble of marking
them.

>> 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.
> 
> 
> OK, let me see if I understand you. So we do emit the "+name not 
> implemented/listed by protocol(s)" warning, and then proceed to
> search for "-name" in the same set of protocols? I guess then you
> should get an additional diagnostic about multiple signatures, just
> as you do when you message 'id <CommonMethodNames1,
> CommonMethodNames2>' (which needs fixing, as I alluded to above)?

Yes, we could emit something "+name not declared by protocol(s)" but we
should then emit something "using '-name' of protocol '%s'".  Then the
prototype search wrt finding conflicting signatures can continue to
cover all further adopted and incorporated/inherited protocols, but it
should not continue to the global prototype list.

> A related issue would be handling constructs like
> 
>     [MyObject<MyProto1, MyProto2> someClassMethod]
> 
> where, I guess, the order of operations would be
>    (1) Look for '+someClassMethod' in Proto1 and Proto2, and report any 
> conflicts; if none found,
>        emit "not listed in protocol(s)" warning;
>    (2) Failing that, look for '+someClassMethod' in MyObject (which may 
> also locate a '-someClassMethod'
>        in its root class); if none found, emit "may not respond to" 
> warning;
>    (3) Failing that, look for '-someClassMethod' in Proto1 and Proto2, 
> and report any conflicts;
>    (4) Failing that, look for '+someClassMethod' in the global hash 
> table (which will also yield '-someClassMethod'
>        from root classes), and report any conflicts;
>    (5) Failing that, emit "cannot find method" warning and select IMP as 
> the signature.
> 
> For the case
> 
>    [Class<MyProto1, MyProto2> someClassMethod]
> 
> that we've been discussing, we would simply elide step (2).
> 
> For completeness,
> 
>     [MyObject<MyProto1, MyProto2> *someInstanceMethod]
> 
> will
>    (1) Look for '-someClassMethod' in Proto1 and Proto2, and report any 
> conflicts; if none found,
>        emit "not listed in protocol(s)" warning;
>    (2) Failing that, look for '-someClassMethod' in MyObject; if none 
> found, emit "may not respond to" warning;
>    (3) Failing that, look for '-someClassMethod' in the global hash 
> table, and report any conflicts;
>    (4) Failing that, emit "cannot find method" warning and select IMP as 
> the signature.
> 
> while
> 
>     [id<MyProto1, MyProto2> someInstanceMethod]
> 
> will elide step (2).  Wow, this is starting to look like a fragment of 
> an early draft of a language spec, so I'll stop now
> before things get out of hand. :-)  Anyway, at least some of this stuff 
> should wait until gcc 4.1 stage 1...

With taking what I said above into account, I think the orders you
proposed are sane.  Let's see how far I get today.

Cheers,
David