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

FROM : Chris Suter
DATE : Tue Oct 14 11:58:10 2008

On Tue, Oct 14, 2008 at 8:17 PM, Oleg Krupnov <oleg.<email_removed>> wrote:
> You are right, casting from alloc worked, thank you.
>
> Is it the recommended practice to always cast after alloc?
>
> I still have a question in this regard.
>
> 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


This won't work. The compiler emits different code depending upon the
types involved. For example, there are differences depending on
whether the return types are structures, floating point or integer
values.

> 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.


Well that would be a pain. You'd get warnings everywhere. id, by
definition, can be sent anything.

> 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?


It comes down to the point I made above. It needs to know about the types.

The proper way to solve this, in my opinion, is to allow a way of
specifying that the return type varies depending on the class it's
implemented on i.e. define the alloc method in such a way so that the
compiler knows that -[<class> alloc] returns an object of type
<class>. Something similar could be used for [NSString string] and
[NSMutableString string] which have a similar problem (they return an
id, rather than an NSString or NSMutableString).

-- Chris