Hi Alexander
> If my class is files owner the whole nib is owned by it - hence the name.
> Therefore I absolutely want IB to be able to set even the private ivars. The
> nib is just another way of setting up my class’ objects.
If I may say so, to say this is to misunderstand object oriented design.
The class that you designate as the File's Owner is a controller class that you
might create from within IB but that I would create in Xcode and assign to the
File's Owner in IB.
Regardless of how you create a controller class, it is entitled to have private
state that is not visible in the NIB file. This is true of all classes that
contain instances of other classes - the containing class's state is not
usually visible in the contained instance, unless the designer of the
containing class explicitly makes it so.
The concept of restricted visibility is relatively new to Objective-C and its
lack has been something that has put me off using the language sooner.
Yes, there will be ivars in the controller class that need to be visible in the
NIB file but the controller may also require other ivars which the designer of
the controller doesn't want to be visible in the NIB.
Although you can setup your controller class from within IB, you are only
really meant to setup outlets and actions that you require to see from the
controller class. You could just as easily setup actions and outlets in Xcode
and use IB to connect to them, which, coming from a more strictly regulated
language, is what I choose to do.
In fact, the latest docs recommend that IBOutlet is now applied to declared
properties, with a private backing ivar, instead of the "old way" of hooking up
directly to the ivar.
Pre-Objective-C 2.0
@interface MyClass : NSObject
{
id delegate;
IBOutlet NSWindow *window;
}
///////////////////
Objective-C 2.0
@interface MyClass : NSObject
{
@private
id delegate;
NSWindow *window;
}
@property (nonatomic, retain) IBOutlet NSWindow *window;
- (id) initWithDelegate:(id)delegate;
@end
@implementation MyClass
@synthesize window;
- (id) initWithDelegate:(id)del;
{
if (self = [super init])
{
delegate = del;
}
return self;
}
- (void) dealloc
{
[window release];
[super dealloc];
}
@end
///////////////
Yes, it may be more code, but it allows developers, used to the enforcement of
visibility in classes, to create a controller that can be instantiated, in
code, with a constructor that takes a parameter of an object that we do not
want the NIB to see or use. In this example, the Objective-C 2.0 version should
allow me to hide the delegate because I don't want anyone accidentally
assigning over it in IB.
Joanna
--
Joanna Carter
Carter Consulting
_______________________________________________
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
