This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: Enhancing ObjC message lookup in the presence of protocols
On 19 Oct 2004, at 12.56, d.ayers@inode.at wrote:
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.
We are not guessing what kind of object clsP2 contains. We would be
using
the information we do have about Proto2 to constrain the fallback to
the
instance method search.
But the most you can say about Proto2 in your example is that none of
the
root classes that you have seen adopt it. Does that mean that _no_ root
class in your program adopts it and/or provides the methods that Proto2
requires?
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 */
Here you have an object, not a class anymore, but that is a different
issue.
True, true... I guess perhaps we should think of notation to denote
class objects
of a specific type? :-)
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 maintain that [cls name] in unambiguous, as we know of only one class
which implements +name. And that is MyRootClass as it adopt my Proto1,
where as Proto2 is adopted merely by a non-root class. It's undisputed
that [obj name] is ambigious.
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.
What I'm trying to show is that "to look through protocols" in the
case of
'Class <protocol>' should heed the information we have about the
protocols
when taking into account the sematics of instance methods of root
classes.
You initially disliked the idea of "protocols adopted by root classes".
In the absence of this infomormation, I conceeded to at least add the
instance methods search for all protocols, eventhough this approach
will
induce false positives as described above. You implicitly affirmed in
this thread that we should adorn protocols with the status "adopted by
root classes" to handle the global class cache correctly. Now I'm
saying,
if we have the infomation with the protocol, why not also use it for
lookup of protocol qualified classes to constrain the instance method
search for adorned protocols.
We "know" that no class has adopted the protocol as a root protocol if
it's not adorned.
But do you know that none of the root classes (even in your own
translation
unit, let alone others) nevertheless provide the method you're looking
for?
For your approach to be fully consistent, shouldn't you _always_ check
which protocols are adopted where? For example, given
id <Foo, Bar, Baz> obj;
[obj mess];
shouldn't you check whether Foo, Bar and Baz have been adopted by some
class somewhere, root or non-root? I really don't think we want to go
down this path, not least because this would entail changing the
long-established semantics of message dispatch. :-(
I think you're implying that "we may have not seen the
header that does", and therefor we shouldn't be using that information.
Not when we're messaging an opaque receiver such as 'Class' or 'id'.
Aside from
collecting encountered method signatures in our global hash tables, we
shouldn't
make any assumptions about the type of the receiver (and, therefore,
whether the
root class of the receiver's hierarchy adopts a given protocol or not).
Anyway, I think we're sort of circling the drain here. :-) I'll update
my patch
to fix the type comparison snafus you found. I think that I'll also
populate
the hash tables with methods from protocols, including handling of
forward-declared
protocols adopted by root classes.
--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