RFC: Enhancing ObjC message lookup in the presence of protocols

Ziemowit Laski zlaski@apple.com
Tue Oct 12 06:11:00 GMT 2004


This is a fallout from the work that David and I have been doing wrt 
adding 'Class <Proto>' support to
the Objective-C language for the gcc 4.0 compiler (which hopefully will 
go in shortly, BTW).

Given the code

   @protocol Proto
    - method1;
    + method2;
   @end

   @interface Base <Proto>
   @end

   void foo(void) {
     Class cls;
     [cls method1];
   }

the compiler will currently warn:

   proto-ref.m:11: warning: `Class' may not respond to `+method1'
   proto-ref.m:11: warning: (Messages without a matching method signature
   proto-ref.m:11: warning: will be assumed to return `id' and accept
   proto-ref.m:11: warning: `...' as arguments.)

Thing is, the compiler could do better in this case.  Since the 'Base' 
class adopts the
'Proto' protocol, it is reasonable to assume that it will provide a '- 
method1' and
a '+ method2'.  Furthermore, since 'Base' is a root class in our 
example, '- method1'
can be invoked as '+ method1', making the warning above superfluous.

My proposal to attack this problem goes as follows:  Whenever we see an 
interface or
category declaration, we examine the protocols adopted by said 
interface/category and
insert their constituent method signature into the global class or 
instance method
hash tables (as is already being done for methods declared by the 
interface/category
directly).  Also, whenever we are dealing with a root class (or a 
category of a root
class), we add any instance methods from the adopted protocols into the 
global
class hash table (just as instance methods directly declared by root 
classes and
categories already are).

Such a fix should prevent us from issuing many superfluous warnings 
when messaging
objects of type 'id', 'id <Proto>', 'Class' and (now) 'Class <Proto>', 
and will make
things more consistent with what happens when you message a specific 
type
(e.g., 'NSObject *').

What do you think?  Does anyone have any objections to this?  I'll be 
happy to clarify
things if my missive is not understandable. :-)

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



More information about the Gcc mailing list