You should get a warning about ambiguous messages, and it also tells you which selector is actually used: Multiple methods named 'width' found Using '-(CGFloat)width'
Then use static typing to resolve the ambiguity (i.e [(Resolution*)object width]) 'treat warnings as errors' is a big help in avoiding issues like this. -Anders On 2011-04-10, at 12:25 , Philipp Leusmann wrote: > Stephen, > > thanks to your detailed answer. This absolutely explains the observed > behavior, but still leaves me wondering about the feature of sending messages > to id. > While I am still new to programming in objective-c and only having read the > basic language documentation, I remember this feature to be pointed out as a > helpful tool. But after this discovery, I can only mark it as a "don't use" > language feature. > > Regards, > Philipp > > Am 10.04.2011 um 10:00 schrieb Stephen J. Butler: > >> On Sat, Apr 9, 2011 at 9:52 AM, Philipp Leusmann <m...@byteshift.eu> wrote: >>> Who can explain this behavior to me? Why is oWidth != object.mWidth ? How >>> can that happen? >> >> It's an artifact of how Objective-C searches for selector >> implementations. You're calling @selector(width) on an "id", and of >> course "id" doesn't implement @selector(width). >> >> So what Objective-C does is search for the first implementation of >> @selector(width) that it finds. My guess is it finds the one in AppKit >> first (greping the frameworks): >> >> NSTableColumn.h:- (CGFloat)width; >> >> Then when the compiler sets up the call site it does it expecting a >> CGFloat return and that is handled differently than an integer. So the >> call site and the implementation of how your width is done disagree >> and you get some strange heisenvalue back. >> >> When you cast the variable to "Result*", Objective-C now knows to use >> YOUR implementation of @selector(width) and it sets up the call site >> properly. > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > 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: > http://lists.apple.com/mailman/options/cocoa-dev/ano%40bahnhof.se > > This email sent to a...@bahnhof.se _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
