Re: Methods with the same name but different return types
Re: Methods with the same name but different return types
- Subject: Re: Methods with the same name but different return types
- From: Andreas Grosam <email@hidden>
- Date: Sat, 04 Jun 2011 08:26:33 +0200
On Jun 3, 2011, at 7:44 PM, Bill Bumgarner wrote:
>
> On Jun 3, 2011, at 8:15 AM, Jens Alfke wrote:
>
>> The drawback is that, in this case, the compiler can’t figure out which version of the ‘overloaded’ selector is meant, which can cause trouble. That’s why you want that compiler warning on. But the warning has nothing to do with arrays; this can happen anyplace where an ‘id’ type is messaged.
>
> What Jens said.
>
> The best solution is to rename your method to avoid the collision.
To be honest, unless you use quite funny names, this seems to be a loosing game. A new SDK can introduce new arbitrary names, and your source code which was OK before may break with a new SDK, a new library or your own new sources, etc..
Then, there are simply no good alternatives for inventing new names. How would you rename "position"?
In order to be sure to avoid such problems we would need to prefix our method names with a unique tag. Or, alternatively, we provide the result as arguments and encode the method name accordingly:
- (void) positionAsFloat:(float*)position;
>
> The second best solution is to make sure that you explicitly typecast everywhere.
While I think this is a better approach, it is not always possible:
Suppose there are objects within the array of different classes which all have a method "position", but have no common ancestor as base class. Here, you would have to use "duck - typing" - and an explicit type cast cannot be applied.
It seems a bit disappointing that when you actually want to use dynamic facilities of the language, it becomes risky as well (in this particular case). The language would need to introduce some kind of "name space" in order to alleviate such issues.
>
> IIRC the compiler should warn if it sees two method declarations with incompatible types and it can't resolve which one to use in the context of the call.
There are two compiler switches (warnings) related to "signature overload" problems:
"Strict Selector Matching"
GCC_WARN_STRICT_SELECTOR_MATCH, -Wstrict-selector-match
"Multiple Definition Types for Selector"
GCC_WARN_MULTIPLE_DEFINITION_TYPES_FOR_SELECTOR, -Wselector
In Xcode 4, both are disabled by default when creating from a template project.
As Eyal experienced, there is in fact the possibility to break existing code, when compiling with a newer SDK. So IMO, it wouldn't hurt if these switches are on by default.
Regards
Andreas _______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden