[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [objc-improvements] Just remembered something about multiplemethod s

From: David Ayers
Subject: Re: [objc-improvements] Just remembered something about multiplemethod signatures...
Date: Tue, 09 Sep 2003 13:43:19 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507

Richard Frith-Macdonald wrote:

1. If the compiler has no signature for a method ... it should generate an error. 2. If the compiler has multiple conflicting signatures ... it should generate an error. 3. If the compiler has multiple signatures which would generate the same code, it should generate a warning.

It sounds like telling the difference between (2) and (3) may be too hard (I certainly don't know how to code that comparison) ... in which case we have to assume (2) for now, but making the distinction between the two cases would be a very good thing.

This is a compromise I can definitely conceed to. But before giving up on whether or not we're able to tell the difference between (2) and (3), I would like to thow up two suggestions for grabs, that effectively distinguish between 'conflicting' and 'compatible' prototypes in my previous mail. a) My first thought was to check return value and arguments in turn, to assert that all corresponding components agree on the same size as determined by sizeof().

This should effectively keep generating "working" code for 'compatible' but 'conflicting' prototypes. The issue this appoach still raises is that we would have to 'construct' a prototype to pass to the C part of the processing, which may otherwise still emit an error (NSSize/NSPoint example) about conflicting types. This construction of a C-type, may in the end be the complexity, that renders this approach not worth the trouble or even impossible. (Besides the fact that others have already effectively veto'ed this :-) )

b) A simpler assumption would be to assume 'id' for all occurances of object references. I think this is the 'merge' that Alex had been refering to (and has also been proposed by Nicola in the meantime). We would still be 'constructing' a prototype, but it should be (relatively) trivial to implement after Alex's patch has been commited. And I believe that will cover almost all potentially 'legitimate' cases of 'conflicting' but 'compatible' prototypes.

If we cannot find a consensus, I can also conceed to retaining the old behavior.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]