|
| From: | Steve Naroff |
| Subject: | Re: [objc-improvements] Merging back to mainline |
| Date: | Sat, 6 Sep 2003 17:18:08 -0700 |
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).
I agree...the compiler needs to be consistent (and not "stop"). If Foo and Bar have conflicts, then the compiler needs to warn.
This is a simple bug to fix.
Interestingly, your example shows precisely the kind of bad things that can happen. :-)
That is why I picked it.
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.
The compiler on my machine doesn't crash. I still don't see the general problem or point you are making.
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.
This isn't a subtle problem at all. The compiler is telling you exactly what it is doing (which as you say might not be what is intended). It is saying there is an ambiguity that it is incapable of understanding.
This is why it is a warning!!! If you don't want the parameter garbled, then you should use stronger typing (by changing the declaration or casting at the call site).
Here is the "culture clash" that I think I am hearing...you think it is objectionable to generate "bad code" for such cases. The only case I consider bad is if the compiler generates bad code *without* warning you that it is confused (or doesn't know that it is confused). Are there such cases? (aside from the composite protocol example mentioned above...)
Here is an analogy...sending a message to a method that does not exist...in ObjC this is an easy mistake to make...in C/C++ it is rare/impossible.
Summary: Supporting dynamic typing atop C has some pitfalls. The design of Objective-C is to enable tight integration with C basic types and warn if there are confusions. Other design points are:
#1: Force all arguments and return types to be objects. This path was not taken for many reasons. #2: Force all objects to be strongly typed. This path was not taken because we support frameworks that benefit from not having strong typing. In fact, Objective-C dynamic typing was one of the key reasons NeXT decided to use it over C++ in '86.
One potential way to help with the problem I think you are talking about is to have a switch that considers some of these cases hard errors. Given the existing code base, I wouldn't feel comfortable making this the default, however it might be a handy tool to help tighten up code that suffers from such ambiguities.
I suggest we get together on Monday and discuss these issues face to face.
snaroff On Friday, September 5, 2003, at 04:54 PM, Ziemowit Laski wrote:
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
| [Prev in Thread] | Current Thread | [Next in Thread] |