Re: Bug in GCC 3.1?
Re: Bug in GCC 3.1?
- Subject: Re: Bug in GCC 3.1?
- From: email@hidden
- Date: Tue, 07 May 2002 08:35:28 -0700
Thomas Lachand-Robert wrote:
|
|Le mardi 7 mai 2002, ` 12:35 , email@hidden a icrit :
|
|> |That's what I meant. This doesn't explain why [self bar:(id)t] doesn't
|> |work, since NOW the object type is unspecified as you say.
|>
|> But "bar:" requires an object that *is* specified, at least to the extent
|> of implementing the NSMutableCopying protocol.
|>
|
|I think you didn't understand my point. It is not directly related to
|protocols, but to cast. An explicit cast to id, or use of an id variable,
|normally removes any compiler warning like in these examples:
True. And had the original code cast the variable "t" simply to "id", unadorned by any protocol declaration, I would agree that a warning would be inappropriate, because a plain old "id" can be anything.
However, in the code in question, "t" was not a plain "id", but "id<NSCopying>". The "id" was no longer just anything. The protocol declaration told the compiler what protocols the object implemented, something it hadn't know previously. The added knowledge caused the compiler to report an apparent mismatch between what "t" was (an object which implemented the NSCopying protocol) and what "bar:' expected (an object which implemented the NSMutableCopying protocol). Had the code been written "[self bar: (id) t]", with the cast making "t" a plain old "id", then a warning would have been incorrect.
The problem is that the cast *wasn't* to "id"; it was to "id<NSCopying>", and the addition of the protocol name makes all the difference. By adding the protocol to the declaration or cast, you no longer have a plain "id", just as adding a class name causes it to cease being a plain "id". Protocols are a type just as much as classes are, even if a different kind of type. Telling the compiler that an object implements a protocol is describing the object as surely as telling the compiler what class the object is. Once you've described the object in any way--once you've said more than just "it's an id"--the compiler is simply doing its job to check that what you're telling it makes sense.
Glen Fisher
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.