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