• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: [Obj-C Compiler Bug?] Two different classes declaring a message with the same name - compiler warning
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Obj-C Compiler Bug?] Two different classes declaring a message with the same name - compiler warning


  • Subject: Re: [Obj-C Compiler Bug?] Two different classes declaring a message with the same name - compiler warning
  • From: Quincey Morris <email@hidden>
  • Date: Tue, 14 Oct 2008 09:59:46 -0700

On Oct 14, 2008, at 02:17, Oleg Krupnov wrote:

If the alloc returns id, then, from the compiler's perspective, there
can be two solutions: 1) assume that the id type can have each and any
method and let it be resolved at run time without any compiler warning
or 2) assume that the id does not have any methods (except NSObject's)
and always issue a compiler warning when there is no explicit casting
to a type. What compiler seems to be doing is rather strange: it looks
through the project, arbitrarily picks up a class with the matching
message name and issues a warning if the rest of the actual message
signature is not matching. How would you explain that?

This is a fairly well-known issue. It reflects an Objective-C design constraint, and does not indicate random or inconsistent behavior in the compiler.


The design constraint is that Objective-C assumes (but does not enforce) that methods with identical selectors have identical parameter and return types. Your initWithContext: methods violate this constraint. It's certainly possible to violate the constraint without danger in particular cases, and it's certainly possible there are places in the frameworks where Apple does it, but the compiler's warning messages reflect the underlying assumption.

When the compiler sees a message sent to an object typed 'id', it checks to see if that message selector is defined at that point in the compilation. If it's not defined, you get a warning (that the object may not respond to that selector). If it's defined consistently in one or more classes that have been included in the compilation, there's no warning. If it's defined inconsistently in two or more classes included in the compilation, it issues the warning you saw. There's nothing arbitrary about it, and the compiler certainly doesn't "look through the project". If you don't include both of your offending class headers, you won't see the warning -- unless of course you're conflicting with frameworks headers that are included.

You may not like this behavior, but that's what it is.


_______________________________________________

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


References: 
 >[Obj-C Compiler Bug?] Two different classes declaring a message with the same name - compiler warning (From: "Oleg Krupnov" <email@hidden>)
 >Re: [Obj-C Compiler Bug?] Two different classes declaring a message with the same name - compiler warning (From: "Chris Suter" <email@hidden>)
 >Re: [Obj-C Compiler Bug?] Two different classes declaring a message with the same name - compiler warning (From: "Oleg Krupnov" <email@hidden>)

  • Prev by Date: Re: intercepting NSBrowser multiple selection extension with shift down/up arrow
  • Next by Date: Re: Finding clicked row in NSOutlineView
  • Previous by thread: Re: [Obj-C Compiler Bug?] Two different classes declaring a message with the same name - compiler warning
  • Next by thread: [CODE] JPDurationToDecimalNumberFormatter
  • Index(es):
    • Date
    • Thread