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

[Ziemowit Laski]

On Tuesday, Sep 9, 2003, at 01:28 US/Pacific, Richard Frith-Macdonald 
wrote:

> I've been following this discussion, but haven't contributed ... 
> partly because others are covering the points I thought of, and partly 
> because I've been ill for the last week, and wasn't sure I was 
> thinking clearly enough to jump in without confusing things more.
>
> However, the discussion of the method signature issue seems to have 
> reached an impasse, and perhaps an additional opinion (something like 
> a vote) is useful.  I'm not saying anything new, but I hope I can 
> clarify the state of the discussion a little ...
>
> One point to bear in mind is that there is no way to get this 
> completely reliable. The compiler simply may not know the signature of 
> a method provided by an object (which could be loaded from a bundle or 
> running in another process and forwarded to).  It is therefore 
> unreasonable to insist that the compiler always generates correct > code.
>
> That being said, my preference is still to minimise the chance of the 
> compiler ever generating incorrect code, so I make the assumption that 
> it is the programmers responsibility to provide the compiler with 
> signatures for every method used, and to (ideally) use casts to 
> resolve ambiguities.  Of course, a programmer uses packages produced 
> by other people, and the headers of new versions of the packages may 
> introduce methods which conflict with those the programmer used 
> privately ... so we need the compiler to help as much as possible in 
> resolving ambiguities.
>
> Taking that assumption  (the compiler knows all the signatures) -
> 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.
>
> The errors and warnings should give as much information as possible 
> about the nature of the ambiguities.
>
> For backward compatibility, we should have a flag to turn the errors 
> into warnings.  When that flag is in use, the code generated should 
> use the old semantics (after all, it is for backwards compatibility) 
> ... ie use IMP where there is no signature, and arbitrarily select a 
> signature otherwise.

Actually, this sounds quite reasonable by me -- thanks, Richard!

--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