Re: [objc-improvements] Merging back to mainline

[Ziemowit Laski <zlaski at apple dot com>]

On Friday, Sep 5, 2003, at 15:28 US/Pacific, Steve Naroff wrote:

> Zem,
>
> What is the disagreement about the handling of conflicting method 
> signatures?
>
> As you know, this is only a problem when using anonymous types (i.e. 
> "id").

Yes (or 'Class'), although a suggestion has been made on the list that 
the check for multiple methods could/should always be made.  For 
example, if your receiver is of type 'id<Foo, Bar>', you're sending a 
message 'foo', protocol Foo has '-(void)bar' and protocol Bar has 
'-(int)bar'.  Currently, the compiler will use the signature from 
protocol Foo and stop.  (This implies that 'id<Foo, Bar>' is not quite 
the same as 'id<Bar, Foo>', intentionally or not).

> Since using anonymous types with multiple method signatures is 
> ambiguous, the only thing the compiler can do is pick one (the first 
> one it encounters is as good as any), warn, and make it clear which 
> version was chosen.
>
> [steve-naroffs-Computer:~] snaroff% cc -c xx.m
> xx.m: In function `main':
> xx.m:20: warning: multiple declarations for method `bar'
> xx.m:6: warning: using `-(void)bar'
> xx.m:12: warning: also found `-(float)bar'

Interestingly, your example shows precisely the kind of bad things that 
can happen. :-)  What if you're trying to do the following?

  obj2 = [obj bar];

The compiler will die with a hard error, since you've (incorrectly) 
picked a 'void' return type.  This was the subject of a Radar (among 
many others pertaining to messaging) that I fixed.

Another, more subtle example is the following:

> xx.m: In function `main':
> xx.m:20: warning: multiple declarations for method `bar'
> xx.m:6: warning: using `-(id)bar:(float)'
> xx.m:12: warning: also found `-(id)bar:(int)'

and suppose you have '[obj bar:123]', and really are calling 
`-(id)bar:(int)'.  But because you're using the `-(id)bar:(float)' 
signature, the compiler will provide int->float conversion behind your 
back, and you'll be mystified as to why your parameter gets garbled 
during the call.  There are many scenarios similar to this one; if 
users are more lucky they'll get mysterious warnings/errors about 
incompatible argument type conversions.

For the same reason, it wrong for the compiler to pick a method 
signature out of a hat if no methods matching the receiver type and/or 
protocols are found.

Warning about multiple signatures is one thing; however, I believe that 
the compiler should be able to gracefully pick up and continue from 
that point.  My proposed solution is to use the generic IMP signature 
whenever there are multiple methods found (or if there are NO methods 
found, which makes the failure mode much more consistent and easy to 
understand).

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