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