• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Code error in Your First Mac App tutorial..
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Code error in Your First Mac App tutorial..


  • Subject: Re: Code error in Your First Mac App tutorial..
  • From: Conrad Shultz <email@hidden>
  • Date: Thu, 29 Dec 2011 18:43:37 -0800

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 (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

  • Follow-Ups:
    • Re: Code error in Your First Mac App tutorial..
      • From: Peter Teeson <email@hidden>
References: 
 >Code error in Your First Mac App tutorial.. (From: Peter Teeson <email@hidden>)
 >Re: Code error in Your First Mac App tutorial.. (From: Ken Thomases <email@hidden>)
 >Re: Code error in Your First Mac App tutorial.. (From: Peter Teeson <email@hidden>)

  • Prev by Date: Re: Code error in Your First Mac App tutorial..
  • Next by Date: Re: Code error in Your First Mac App tutorial..
  • Previous by thread: Re: Code error in Your First Mac App tutorial..
  • Next by thread: Re: Code error in Your First Mac App tutorial..
  • Index(es):
    • Date
    • Thread