Le 18 juin 2010 à 17:05, Jonny Taylor a écrit :
> Thanks for your reply Jean-Daniel.
>
>>> I can see two ways of working around this - either implement placeholder
>>> methods in the base class (that raise an exception or something) in order
>>> to make the base class conform to the protocol (knowing that in practice
>>> they should always be overridden by a subclass), or have the subclass pass
>>> its "self" pointer to the base class in the form of an id<MyProtocol> that
>>> the base class uses when it needs to call such methods. Both of these leave
>>> me feeling pretty dirty, though.
>> Adding stub methods that raise an exception seam a good way to solve the
>> problem (that what all class cluster abstract class do in Cocoa Framework).
>
> The reason I wasn't wild on this is that it stops me getting compile-time
> warnings saying that the protocol is not fully implemented (since the base
> class fully implements it). There will be run-time errors when the
> non-overridden base class stub is hit. Maybe that's the best of the available
> choices, though. I just hoped there would be a "proper" way around this. I'm
> sure the language designers are far smarter than me and had good reasons for
> what they did, but I do miss abstract base classes!
Yes you will get error at runtime instead at compile time. That the main
difference between a strongly typed, static language (c++), and a language that
support dynamic typing and binding.
That's the proper Obj-C way, In Obj-C there is a lots of implicit contracts
that could not be enforced by the compiler due to the dynamic nature of the
language.
For example, it's perfectly legal in obj-c to declare a method without
implementation as the implementation can be loaded at runtime or dynamically
generated.
Note that an other way to get ride of the compiler warnings is to create a
extension interface (without implementation):
in MyBaseClass.h:
@interface MyBaseClass : NSObject {
}
@end
@interface MyBaseClass (MyProtocol) <MyProtocol>
@end
in MyBaseClass.m
@implementation MyBaseClass
// implements only a subset of the protocol
@end
But here again you will get runtime errors and no warning if a subclass does
not override the missing methods (or call super implementation).
-- Jean-Daniel
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
