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

FROM : Graham Cox
DATE : Tue Oct 14 13:31:29 2008

On 14 Oct 2008, at 10:11 pm, Chris Suter wrote:

> I believe the fact that they are class clusters is irrelevant; it's an
> implementation detail. The objects returned still conform to the
> interfaces defined by NSString and NSMutableString. They return id,
> rather than NSString say, because otherwise you'd get a compiler
> warning if you tried to do something like:
>
>    NSMutableString *string = [NSMutableString string];


Well, that was my point. Maybe my terminology was incorrect - the 
point is that returning id allows this convenience with classes that 
derive from a common base. That isn't the case with the OP's code. He 
has two entirely separate classes that happen to share the same init 
method name. They *could* return the class type instead of id, as long 
as he doesn't plan to subclass them further. Whether that's OK in his 
case would have to be considered.

>> but for your own classes, you could define your
>> init... method to return the specific object type.

>
> You can't override the type for existing methods. For example,
> initWithString: always returns an id. You can define them as returning
> something different but the compiler will ignore it.



I'm not talking about existing methods. I'm talking about the unique -
initWithContext: methods that the OP defined.

I'm not even saying it's a good idea - I'd always return id from an 
init method because that's least confusing all round. And, as I said, 
I don't think it would help anyway - the return type is ignored when 
determining which of a pair of otherwise identically named methods to 
compile against. In fact this last point is potentially dangerous as I 
found out to my cost earlier this year (e.g. see: http://www.cocoabuilder.com/archive/message/cocoa/2008/6/5/209327)

>> Best solution is just not to make the methods look the same.

>
> That's not always convenient. For example, it's nice to be able to do
> [NSString initWithString:] and [NSMutableString initWithString:].


Yes. My point was that the OP has the option to do this, because it's 
his own code. I'm not advocating for one microsecond that anything in 
Cocoa should be changed. Well, at least not on this one point. ;-)

--Graham