RFC: Enhancing ObjC message lookup in the presence of protocols

Ziemowit Laski zlaski@apple.com
Tue Oct 19 15:15:00 GMT 2004


On 18 Oct 2004, at 5.29, David Ayers wrote:

> Let's try this example
>
> @protocol MyProto1
> - (const char *)name;
> @end
>
> @protocol MyProto2
> - (NSString *)name;
> @end
>
> @interface MyRootClass <MyProto1>
> @end
>
> @interface OtherRootClass
> @end
>
> @interface MyClass : OtherRootClass <MyProto2>
> @end
>
> In this case <MyProto2> is not a protocol declared by a root class. 
> Therefor we should not be falling back to the instance methods in the 
> case of:
>
> Class <Proto2> clsP2;
> [clsP2 name]; /* may not respond */
>

I guess you meant '/* not implemented by protocol(s) */', right?  If we 
were _never_ to look at instance methods in these cases, then 'not 
implemented by protocol(s)' would be right.  However, since we agreed 
that we should look at instance methods in protocols should class 
method lookup fail, I do not think we should attempt to guess what type 
of object 'clsP2' is actually pointing at.

So, '[clsP2 name]' above should result in the compiler telling you 
'found -name instead of +name in protocol(s)', and then using '- 
(NSString *)name' out of Proto2.

Alternatively, if you know what type of object 'clsP2' was pointing at, 
then you should type it appropriately, e.g.,

   SomeClass <Proto2> *clsP2;
   [clsP2 name];  /* this will issue a more precise diagnostic */


> Class cls;
> [cls name]; /* OK */
>
> should not be ambiguous as there is only one prototype declared by 
> MyProto1 which should be in the class hash table.

Yes, it _should_ be ambiguous, since you will have two conflicting 
method signatures, just as with

   id obj;
   [obj name];

which is also ambiguous.

I guess my overall point is: 'Class' and 'id' may hold an object of 
_any_ ObjC type, and not just types that you happen to have seen in 
your own translation unit thus far.  Protocol lists attached to 'Class' 
or 'id' give you an opportunity to look through the protocols first, 
but again without regard to what the underlying object type might or 
might not be.

--Zem



More information about the Gcc mailing list