On 12/29/11 6:07 PM, Peter Teeson wrote:
> The declaration in the Interface .h file, generated by making the Outlet
> connection. is:
> @property (weak) IBOutlet NSTextField *textField;
> To me that @property statement gives the explicit name textField.
> The generated @synthesize statement in the Implementation file is the one
> that assigns _textField isn't it?
>
> I understand that I could have used _textField. In fact in my research I
> tried it and it worked.
> Similarly for the other iVars window/_window and mute/_mute.
> Doing the digging is what led to me conclude there is some general rule which
> I do not yet know.
>
> I understand there is a special meaning for vars beginning with under bar but
> I still have to refresh my memory on
> Obj-C 2.0.
>
> So I repeat my question; can someone please explain why I had to use
> self.textfield?
"textField" is the name of the *property*. "_textField" is the name of
the (private) *instance variable* (ivar) that is backing the property.
This might be a little less confusing if the names weren't so similar.
Consider analogously:
@property (weak) IBOutlet NSTextField *phoneNumberField;
@synthesize phoneNumberField = internalRepresentationOfPhoneNumberField;
In this case, you would have a *property* called "phoneNumberField" that
you might, for example, connect in Interface Builder to a field holding
a phone number.
You would have an *ivar* called
"internalRepresentationOfPhoneNumberField" that stores the actual
(pointer to) the property.
You could then access the property with:
self.phoneNumberField or [self phoneNumberField]
What @synthesize is doing is, for all practical purposes, creating a
-(NSTextField *)phoneNumberField
method that you call to access the property of that name.
You could access the ivar directly with
internalRepresentationOfPhoneNumberField. What the combination of
@property and @synthesize is doing is, roughly, equivalent to manually
writing:
@interface MyClass : NSView {
@private
__weak NSTextField *internalRepresentationOfPhoneNumberField;
}
- (NSTextField *)phoneNumberField;
- (void)setPhoneNumberField:(NSTextField *)newtextField;
@end
@implementation MyClass
- (NSTextField *)phoneNumberField {
return internalRepresentationOfPhoneNumberField;
}
- (void)setPhoneNumberField:(NSTextField *)newTextField {
internalRepresentationOfPhoneNumberField = newTextField;
}
@end
(Typed in mail, and omitting the IBOutlet semantics.)
You should be able to see from this expanded example why you would then
need to use either "[self phoneNumberField]" OR
"internalRepresentationOfPhoneNumberField".
Does that help at all?
Why does this matter? In part because properties do not actually need
to be backed by ivars. For example, you might have a class that manages
student performance and has an interface that hypothetically looks like:
@interface ExamCollection : NSObject {
}
- (void)addExam:(Exam *)anExam;
- (void)removeExam:(Exam *)anExam;
@property (readonly) NSNumber *averageExamScore;
@end
@implementation ExamCollection
...
- (NSNumber *)averageExamScore {
// Loop over exams and return the computed average
}
@end
(A real world example of a readwrite property that is not backed by an
ivar is UIView's frame on iOS, but that makes for a more complicated
discussion... read up on it if interested. :-)
--
Conrad Shultz
Synthetiq Solutions
www.synthetiqsolutions.com
_______________________________________________
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
