From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24493 invoked by alias); 18 Oct 2004 12:29:57 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 24463 invoked from network); 18 Oct 2004 12:29:54 -0000 Received: from unknown (HELO smartmx-05.inode.at) (213.229.60.37) by sourceware.org with SMTP; 18 Oct 2004 12:29:54 -0000 Received: from [83.64.80.47] (port=5344 helo=[83.64.80.47]) by smartmx-05.inode.at with asmtp (Exim 4.30) id 1CJWe3-0000j1-N2; Mon, 18 Oct 2004 14:29:47 +0200 Message-ID: <4173B73F.2000201@inode.at> Date: Mon, 18 Oct 2004 16:31:00 -0000 From: David Ayers User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 MIME-Version: 1.0 To: Ziemowit Laski CC: gcc List , objc-language@lists.apple.com Subject: Re: RFC: Enhancing ObjC message lookup in the presence of protocols References: <728118AE-1BD1-11D9-9ABE-000D9330C50E@apple.com> <416E8E83.7000409@inode.at> <41700249.2080206@inode.at> <323992E2-2091-11D9-9E96-00039390FFE2@apple.com> In-Reply-To: <323992E2-2091-11D9-9E96-00039390FFE2@apple.com> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-10/txt/msg00694.txt.bz2 Ziemowit Laski wrote: > On 15 Oct 2004, at 10.00, David Ayers wrote: > > I'm with you as far as putting these in the hash table. I'm also willing > to go along with specially marking protocols that are adopted (directly > or indirectly) by root classes, but not yet defined, so that we may inject > their methods into said hash table later. The reason I say "go along" is > that one could plausibly view a forward-declared (but not yet defined) > protocol as _intentionally_ opaque. > Well if it is indeed /only/ forward-declared, then it will remain opaque. Yet if it is later declared (i.e. before the methods are used) I cannot see a reason why not to use the prototypes for code generation. >> So now we have the >> "protocols adopted by root classes" marked, and we can use that >> information during method lookup, do constrain the 'Class ' >> lookup only to those marked protocols. And now we're not only >> potentially a tad bit faster but also more correct in the sense that we >> reduce the potential of finding bogus cases of conflicting protocols! > > > And this is where you lose me. :-( If you have > > @protocol Proto1 > - (const char *) message; > + (int) value; > @end > > @protocol Proto2 > - (NSString *) message; > + (float) value; > @end > > id idP1P2; > Class clsP1P2; > > then the following four message sends below are _all_ inherently ambiguous: > > [idP1P2 message]; > [idP1P2 value]; > [clsP1P2 message]; > [clsP1P2 value]; > Absolutely agreed! > > Your proposal is to leverage additional information, such as > > @interface Root > @end > > to infer that '[clsP1P2 message]' refers to '- (const char *) message' > (BTW, would you make the same argument wrt '[idP1P2 message]', > thereby changing existing behavior?). However, just because you > haven't seen a > > @interface Root2 > @end > > or, for that matter, > > @implementation Root3 > - (NSString *)message { .... } > @end > > does not mean that they do not exist in some translation unit making > up your program. Far from making your message dispatch 'more > correct', you are lulling yourself into a false sense of correctness > by selectively ignoring conflicts that the ObjC type system (FWIW :-) > ) shows you are there. This is not the case I'm worried about and not the case I'm trying to deal with. As you very well described, it is ambiguous and I view it as undefined behavior if a Class / object adopts protocols with incompatible signatures. Let's try this example @protocol MyProto1 - (const char *)name; @end @protocol MyProto2 - (NSString *)name; @end @interface MyRootClass @end @interface OtherRootClass @end @interface MyClass : OtherRootClass @end In this case 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 clsP2; [clsP2 name]; /* may not respond */ and the case: 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. I am aware that in the first case above the compiler does fall back to /use/ the prototype from the class hash table of the second case, but the user has been warned, so that's fine. We do avoid using the instance signatures of MyProto2 incorrectly. I'm less worried about the cases you described, where the fact that MyProto2 is first used as a non-root protocol and later found to be adopted by a root class. I think we should only use the information that we've seen up to the point where we need it. Cheers, David