Re: Hiding superclass methods
Re: Hiding superclass methods
- Subject: Re: Hiding superclass methods
- From: Brock Brandenberg <email@hidden>
- Date: Thu, 9 May 2002 19:07:15 -0500
If you want your view to work when loaded from a nib file, you're
pretty much forced to have *no* initializer (not even initWithFrame:),
and to call a separate setData: method to supply the data. Views loaded
from nib files never have initializers called, not even initWithFrame:,
so any code you might put there would be executed only if you created
the view explicitly in your application. (Initialization of views
loaded from nib files has to be done in awakeFromNib.)
Glen Fisher
You're right in that I'm not loading these subclasses from a nib file.
To make it clear to any newbies, though, the initWithFrame: method does
get called on objects loaded from a nib file when the objects are
instantiated in a content view or another superview. It's just that you
can't do any initialization that requires IBOutlet variables to access
other data because they're not initialized until awakeFromNib: is
called. I'm assuming that you're referring to creating instances of
NSViews by dragging them into the "Instances" tab of the main nib file
window? I haven't done that yet, so I don't know how they would behave :)
If you don't intend your view to ever be loaded from a nib file, then
I'd have initWithFrame:data: be the designated initializer (which is
what you seem to want), then define an initWithFrame: method that
simply writes a message to the log indicating it was called when it
shouldn't be. (The "stub" initWithFrame: should release the view and
return nil, to prevent the calling code from using a half-constructed
object.)
Glen Fisher
You can't do that at the compiler level, but you can redefine the method
in your class, in such a way that it throws an exception (or display an
error messgae, whatever). That's the usual way to "remove inheritance"
of
a method.
Thomas Lachand-Robert
You can't get the compiler to warn you about this (at least not by
any reasonable means). But if you apply the designated-initializer
concept, it shouldn't be a problem in practice. It sounds like
-initWithFrame:data: should be the designated initializer of
BrockView:
@interface BrockView : NSView
// This method calls -initWithFrame:data:, passing a default
// value for the second argument.
- (id)initWithFrame:(NSRect)frameRect;
// Designated initializer. This method does [super initWithFrame:].
// It is the only place in BrockView where [super initWithFrame:]
// is called. <=== just make sure this is true
- (id)initWithFrame:(NSRect)frameRect data:(NSData *)viewData;
@end
Andy
The only reasonable way is to catch the thing at runtime, and that
could be done easily using doesNotRecognizeSelector:.
Ondra Cada
These are great suggestions. The designated initializer seems the most
proper way to do it, writing out debug info from the method that
overrides the superclass initializer. I didn't even know about the
doesNotRecognizeSelector: method until searching the NSObject header.
The reason I want to do this is that I have separated a number of NSView
subclasses from the data that they display (raster images, glyphs,
vector data, etc.). I need to display the data in different ways, so I
have a number of unique views. I'd like to instantiate them with a
pointer to their source data, then notify them of later changes (as they
happen) to that data using the notification mechanism. The data will
always exist before the view, so I'd like to pass it in at
initialization and I simply wanted to "plant flags" during development
to prevent inadvertent use of the wrong method. Doing this usually saves
debugging time later because potential errors are fresh on my mind and I
know that I'm likely to screw up sometime in the future when deadlines
close in.
Before doing something like this, I thought that I might be missing
something more obvious or inherent to Objective-C.
Thanks for the help,
Brock Brandenberg
----- industrial design @ bergdesign.com ------
_______________________________________________
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.