Re: Your 'Class <Protocol>' Work

[Ziemowit Laski <zlaski at apple dot com>]

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] ...

I guess as things currently stand, the first call will silently pick 
CommonMethodNames1's
version of '-name'.  I think we should make the behavior here more 
consistent with
what a brute-force hash table lookup would do, namely warn about 
multiple '-name' signatures
being available (and then still pick CommonMethodNames1's).

The second call, in my opinion, should tell you that '+name'
is not implemented by protocol(s).  (This raises a separate, tangential 
issue:
protocols don't really implement things -- perhaps "not listed in 
protocol(s)"
would be better?)

> 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)?

Actually, I think this would be fine!  Let's see if other people on the 
list have opinions on the matter.

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...

--Zem

--------------------------------------------------------------
Ziemowit Laski                 1 Infinite Loop, MS 301-2K
Mac OS X Compiler Group        Cupertino, CA USA  95014-2083
Apple Computer, Inc.           +1.408.974.6229  Fax .5477