In this situation XCode4 did not show a warning. Philipp
Am 10.04.2011 um 13:44 schrieb Anders Norlander: > 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
