Objective-C n00b questions... when to use self?

[speg]

So I'm just playing around with some iOS stuff and doing some beginner stuff. But I'm not sure when or why you can use self references.

Here's an example from the "The Elements" example:

The class has two properties:
portraitWindow
tabBarController

Then when they go to set it up they use:
self.portraitWindow = localPortraitWindow;

... and two lines later:
[portraitWindow setBackgroundColor:[UIColor blackColor]];

^Why not use self.portrait here? Is it because this is the objective-c style [] message and above was the dot.syntax style? I can accept that...

but THEN on the next line they use the other property:

tabBarController = [[UITabBarController alloc] init];

WHAT! That's not [objective-c [] messages, but it doesn't use self. either...

but if i remove the self. from the very first example (self.portraitWindow = x) and just have "portraitWindow = x" like the tabBarController line, it crashes.

(Adding self. to the second and third examples works fine, so really, I have no idea when/where I should be using it and why or why not.)

Any insight?

 

[Markbnj]

Objective-C is almost entirely built on convention, and often you can do things two, three, or ten different ways. As far as I know the only time . access notation is absolutely required is when you want to ensure that the getter/setter are called rather than accessing the field directly. In the case of the first example you posted the setter for portraitWindow will probably be calling retain on the reference localPortraitWindow, so you need to use . access to make sure it is called. In the method call example there is no such reason, but you could use it if you wish.

 

[Oyster]

Good thing this crap isn't used for building enterprise applications. Hot dayum.

 

[Patterner]

Objective-C is almost entirely built on convention, and often you can do things two, three, or ten different ways. As far as I know the only time . access notation is absolutely required is when you want to ensure that the getter/setter are called rather than accessing the field directly. In the case of the first example you posted the setter for portraitWindow will probably be calling retain on the reference localPortraitWindow, so you need to use . access to make sure it is called. In the method call example there is no such reason, but you could use it if you wish.

I'll admit I'm not 100% clear on the rules (there are some, but I've only discovered them by running into them). One that comes to mind is accessing a property of a property (not sure this is universally true, but it is for CGPoints...maybe it's a CoreGraphics thing). For example, if I have a shape that has a CGPoint as a property and I want to hit the x or y coordinate of that point, instead of using

[[someShape somePoint] x]

you'd have to use

[someShape somePoint].x

(which feels a little weird).

But back to the OP, yes there are different ways of accessing those, but if your (book? tutorial? You didn't say) keeps switching around like that, I would RUN, not walk, and find another one. Learning the Obj-C message system is silly enough (especially if you're used to a more regular dot notation language), that having them do it in different styles from one line to next in the same method is just more pain than anyone should deal with. Looking at the examples, I personally would use

[self setPortraitWindow: localPortraitWindow]

(assuming it's a property). Since I prefer to make setter and getter calls explicit for clarity, plus it helps me get used to the Obj C message calling convention.

I'm personally fond of the Big Nerd Ranch book, with Programming in Objective C by Kochan as a reference. It doesn't teach programming concepts, but does a pretty good job with Obj C basics, Foundation and UIKit stuff. Plus it keeps a nice consistent code style throughout.

 

[Markbnj]

I'll admit I'm not 100% clear on the rules (there are some, but I've only discovered them by running into them).

Heh, that is, for the most part, iOS development in a nutshell.

 

[speg]

Ah, I think I get it.

There is retain, so you have to use self.portraitWindow to call the proper setMethod, otherwise... it would just assign the value without using the setMethod?

...but the tabController is not set this way... so is it not being retained? :\

This is just an example app from the developer docs, so there isn't much guidance.

 

[Markbnj]

Ah, I think I get it.

There is retain, so you have to use self.portraitWindow to call the proper setMethod, otherwise... it would just assign the value without using the setMethod?

...but the tabController is not set this way... so is it not being retained? :\

This is just an example app from the developer docs, so there isn't much guidance.

That's correct. If you look at the property declarations for the interface you'll see which ones are marked as "retain". Those properties need to be accessed through the setter and released when they are no longer needed.

As for the tab controller instance, there is usually only one of these and the os will tear it down with other graphical objects when the app exits, so there may not be a need to retain it.