Re: Obj-C question: protocol usage and inheritance
Re: Obj-C question: protocol usage and inheritance
- Subject: Re: Obj-C question: protocol usage and inheritance
- From: Ondra Cada <email@hidden>
- Date: Tue, 17 Sep 2002 14:07:00 +0200
On Tuesday, September 17, 2002, at 05:52 , Normand Rivard wrote:
"A class is said to conform to a formal protocol if it adopts the
protocol or inherits from a class that adopts it. " This could mean that
MySuperClass should also conform to the protocol MyClassType to shut up
the warnings. The problem is that in general, it doesn't make sense
(although it might in my specific case).
If someone from Apple from the compiler group can reply to this, I would
appreciate. My opinion is that a class should be said to conform to a
formal protocol if it adopts the protocol **by implementation or
inheritance** or inherits from a class that adopts it.
The problem is that the compiler gives me warning because name and
setName are not implemented in MyClass (which is true: these methods
are inherited from MySuperClass). I thought the compiler would notice
that MyClass has access to these methods by inheritance.
I am not entirely sure whether I understand you properly -- seems to me
you are messing up two totally independent points (correct me please if I
am wrong):
(a) a class conforms to protocol if and only if it adopts it itself, or
some of its superclasses adopts it (directly or by protocol inheritance)
This is IMHO completely sensible and unquestionable. Effectively it says
nothing less and nothing more than so as -conformsToProtocol: returned YES,
somewhere in the appropriate class or its superclass the protocol (or
some protocol which contains it) MUST be EXPLICITLY placed in those <...>.
(b) the compiler is endeavouring to help you not to forget something by
prividing a warning in case your implementation does not contain all the
methods from all the protocols adopted explicitly by the class.
This is just a convenience warning, which has *NOTHING* to do with
protocols per se, with adoption of them, or with conforming to them. If
you don't like the warning, switch it off. Anyway, it *DOES NOT* limit
your usage of protocols *ANYHOW*. (A very good example of the same
situation is the warning of assignment in conditional expression ("if (a=1)
..."), which again can be emitted in perfectly valid situations, is there
just to help you, and never limits anyhow the usage of if or assignments.)
And although I agree that it would be nice if the compiler was a bit more
clever when judging whether the protocol is implemented fully or not, it
is very important to realize that it CANNOT DO THAT in general case ANYWAY!
Since, for example, this class very correctly and completely conforms to
the protocol Foo, but the poor compiler has *NO WAY* to guess that you
have implemented it properly:
@interface Foo:NSObject <Foo> {
NSProtocolChecker *foo;
}
@end
@implementation Foo
-init {
if (!(self=[super init])) return nil;
foo=[[NSProtocolChecker alloc] initWithTarget:nil
protocol:@protocol(Foo)];
return self;
}
-(NSMethodSignature*)methodSignatureForSelector:(SEL)sel {
return [foo methodSignatureForSelector:sel];
}
-(void)forwardInvocation:(NSInvocation*)inv {
NSLog(@"Wow, %@ called, doin' nothin' as customary
;)",NSStringFromSelector([inv selector]));
}
@end
---
Ondra Cada
OCSoftware: email@hidden
http://www.ocs.cz
private email@hidden
http://www.ocs.cz/oc
_______________________________________________
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.