Re: pure virtual methods?
Re: pure virtual methods?
- Subject: Re: pure virtual methods?
- From: Sailor Quasar <email@hidden>
- Date: Thu, 24 Jul 2003 15:35:40 -0400
On Thursday, July 24, 2003, at 02:28 PM, Francisco Tolmasky wrote:
Ok, in C++ if I made a method virtual =0, then subclasses would have
to define it. I want to do something similar in Objective C. I have
a class that inherits from NSObject but is to be used as a superclass.
It shouldn't be a protocol because it defines and does a lot of the
dirty work in the background, but all subclasses *should* define and
implement a number of methods. How can I ensure this happens without
making a separate protocol that people would have to make subclasses
adhere to?
The nature of ObjC makes it pretty much impossible to have true "pure
virtual" methods, but there is a workaround. Define the methods in the
superclass, and have code therein that does something like this:
[NSException raise:NSInternalInconsistencyException format:@"%@ was
called in the base class %@!\n", NSStringFromSelector(_cmd), [self
class]];
An exception will be raised (natch) at runtime if the base method is
called (subclasses must be careful not to call [super whateverMethod]).
The exception format I gave in this example will log the selector and
the base class name. If you were feeling particularly naughty, you
could turn this into a macro that takes a parameter (the base class it
should check for).
Obviously, raising an exception might not be the best error reporting
method for you. It's not possible to my knowledge to check this sort of
thing at compile-time, but at runtime you also have the option of a
simple NSLog() (program execution will continue).
If you wanted to be Really pedantic about it, you could also write
something like this as the designated initializer of the base class:
- (id)init/* with whatever? */
{
if ((self = [super init]))
{
if ([self isMemberOfClass:[ThePureVirtualClass class]]) //
isMemberOfClass checks for exactly the given class. This differs from
isKindOfClass, which would accept subclasses of the given class.
{
[NSException raise:/* blah blah blah */];
// OR
[self release];
return nil;
}
// continue normally
}
return self;
}
This will prevent objects of the base class (as opposed to any
subclasses) from being created at all.
You would have to do something similar in awakeFromNib if you intended
for objects of the class to be embedded in a nib. Of course, error
reporting from within nib awakening is a little more difficult than
from an initializer.
-- Sailor Quasar, High Codemaster of the Web, scourge of systems
MacOS is to Windows as Terminus is to Trantor.
Email: email@hidden
_______________________________________________
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.