Re: init method ambiguity
Re: init method ambiguity
- Subject: Re: init method ambiguity
- From: Fritz Anderson <email@hidden>
- Date: Thu, 4 Nov 2010 07:55:59 -0500
On 4 Nov 2010, at 7:23 AM, Jonny Taylor wrote:
> If instead I write:
> [(MyClassA*)[MyClassA alloc] initForCamera:cam];
> then I do not get a warning. This leads me to believe that what I am writing is not actually doing anything wrong, and the compiler warning is associated with the fact that [MyClassA alloc] returns a plain id leaving the compiler to do some deducing about what the type actually is. This, combined with the confusion of having two methods (for different classes) with the same name but different parameter types, seems to be confusing things.
>
> One workaround is to include explicit casts like I have shown. However this leaves me wondering whether it goes against convention and/or recommendations to have two init methods with the same name but different parameter types, even for two unrelated different classes (hard to enforce - one could imagine completely different codebases colliding by chance in this respect). Can anybody comment on this?
Your assessment is completely correct.
Whether you can live with two initializers with the same selector but different parameter types is up to you. As you say, you can't in principle avoid such collisions. Casting is particularly important in the case where the parameters differ among pointer, scalar, and struct types — then the generated code for the call is (can be) different, and if the compiler passed them, the resulting bugs could be inscrutable.
I guess the solution that gives you the best chance of avoiding collisions without casting is to give the two methods signatures you can hope are unique: initQICameraForCamera:, initPSCameraForCamera:. But that's still not an in-principle solution.
Me, I'd wait for warnings, and cast when I need to.
— F
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden