Re: Private ivars, not marked as IBOutlet, visible in IB
Re: Private ivars, not marked as IBOutlet, visible in IB
- Subject: Re: Private ivars, not marked as IBOutlet, visible in IB
- From: Joanna Carter <email@hidden>
- Date: Sat, 13 Mar 2010 15:20:41 +0000
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 (email@hidden)
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:
This email sent to email@hidden
| References: | |
| | >Re: Private ivars, not marked as IBOutlet, visible in IB (From: Lynn Barton <email@hidden>) |
| | >Re: Private ivars, not marked as IBOutlet, visible in IB (From: Joanna Carter <email@hidden>) |
| | >Re: Private ivars, not marked as IBOutlet, visible in IB (From: Thomas Engelmeier <email@hidden>) |
| | >Re: Private ivars, not marked as IBOutlet, visible in IB (From: Joanna Carter <email@hidden>) |
| | >Re: Private ivars, not marked as IBOutlet, visible in IB (From: Alexander Spohr <email@hidden>) |