tags:

views:

119

answers:

5

I'm a new iPhone/Objective-C developer and as I'm going through different tutorials and open source code, I am having a bit of a problem understanding when to use the square brackets "[ ]" and when to use the period " . " for accessing properties/methods of an object.

For example, this code:

- (void)setSelected:(BOOL)selected animated:(BOOL)animated {

  [super setSelected:selected animated:animated];

  UIColor *backgroundColor = nil;
  if (selected){
    backgroundColor = [UIColor clearColor];
  } else {
    backgroundColor = [UIColor whiteColor];
  }

  self.todoTextLabel.backgroundColor = backgroundColor;
  self.todoTextLabel.highlighted = selected;
  self.todoTextLabel.opaque = !selected;

  self.todoPriorityLabel.backgroundColor = backgroundColor;
  self.todoPriorityLabel.highlighted = selected;
  self.todoPriorityLabel.opaque = !selected;
}

Why does [UIColor clearColor] get brackets, but todoTextLabel.backgroundColor get the period?

Could someone explain this easily for me?

A: 

Yep, I just started learning this too:

Unlike other languages, syntax to invoke a method on an object is not objName.someMethod();

It's [objName someMethod]

The dot operator is used to either get or set the value of a property in a class. It's a short way of doing something.

The dot operator, as I have seen it, is always used on an instance of an object whereas the [...] can be used on either an instance of an object or statically (using the class name).

todoTextLabel can use the [] also but using the dot operator is just shorter hand...otherwise you would have to provide parameters, etc, and that's just longer notation.

Hope this helped.

vinnybad
+8  A: 

The convention I have seen in new code is to use the dot for properties, and always use square brackets for messages/selectors (what you call methods). The dot was introduced in Objective-C 2.0, so the disagreement of information you find online is not entirely unexpected.

It's also entirely possible to use square brackets for everything, still (and I do):

foo = [myObject backgroundColor];
[myObject setBackgroundColor:foo];

is equivalent to

foo = myObject.backgroundColor;
myObject.backgroundColor = foo;

To reiterate, you should not be using the dot for messages, only properties.

To answer your specific question, [UIColor clearColor] belongs in brackets because it is not a property; it's actually a class message to UIColor (+(UIColor)clearColor).

You sound like you come from a Java world, so this might be helpful:

MyObject *foo = [[MyObject alloc] initWithAwesome:YES];    /* MyObject foo = new MyObject(TRUE); */
[foo doSomethingWithNumber:5 andString:"five"];            /* foo.doSomething(5, "five"); */
MyColor *bar = foo.faceColor;                              /* MyColor bar = foo.faceColor; */
MyColor *baz = [foo faceColor];                            /* MyColor baz = foo.faceColor; */
foo.backColor = bar;                                       /* foo.backColor = bar; */
[foo setUndersideColor:baz];                               /* foo.undersideColor = baz; */

The "setXXX" and "XXX" messages come from synthesized dynamic properties, and are an Objective-C idiom. The "dot" is simply a shorthand for calling those methods, and is roughly equivalent.

EDIT: Now that I've got some upvotes, time to make some of you reconsider >:)

I never use dots, and neither should you.

Jed Smith
could you provide any rationale for your prohibition against dot notation?
Phil Nash
bad, bad, programmer!
pxl
@Phil Nash: It makes the code less clear. When I see brackets, I always know something is happening -- a dot makes that less obvious. Dots to me feel like an assignment, not a message. I had this impression before I read the Big Nerd Ranch blog post on it, and they agree with me. It's just syntactic sugar that encourages bad habits, and as a working programmer I know to keep my habits clean. I'm not scared of the brackets, but some people seem to be.
Jed Smith
I should also clarify that I do use @property, @synthesize, and @dynamic in my code.
Jed Smith
@pxl: I really, really hope you were kidding.
Jed Smith
There's nothing wrong with using dot notation, as long as you separate out the use to be confined to instance variable access and possibly virtual decorator read-only properties. It's when READING a property has side effects that should should really step back and ask yourself why is this not a real method.
Kendall Helmstetter Gelner
+2  A: 

Big Nerd Ranch has some thoughts on the dot notation that are worth reading.

There's also a rebuttal.

nall
These were good reads, and good to see that the idiom I picked up when I saw dot notation is encouraged by BNR.
Jed Smith
I think the rebuttal is mandatory reading and makes clear just why dot notation is a good idea - along with the proper use. I had the same objections to the dot notation obscuring intent, to me it makes intent more clear.
Kendall Helmstetter Gelner
+1  A: 

By (strong) convention, property accessors are written as methods named after the instance variable for the getter, and the (capitalised) instance variable name prefixed with "set" for the setter (so for instance variable foo you'd have foo and setFoo).

As others have pointed out, as of Objective-C 2.0, if you write object.foo, it will map onto method call [object foo] if getting or [object setFoo: arg] for setting. You can use either form, and some people continue to prefer the full method syntax even when using Objective-C 2.0 exclusively.

A separate, but related, addition to Objective-C 2.0 are the @property/@synthesize/@dynamic keywords for generating the getters and setters. You can mix and match these with dot notation - one does not require the other.

Phil Nash
+4  A: 

I use dot notation for properties because,

for ( Person *person in group.people){ ... }

is a little easier to read than

for ( Person *person in [group  people]){ ... }

in the second case readability is interupted by putting your brain into message sending mode, whereas in the first case it is clear you are accessing the people property of the group object.

I will also use it when modifying a collection, for instance:

[group.people addObject:anotherPerson];

is a bit more readable than

[[group people] addObject:anotherPerson];

The emphasis in this case should be in the action of adding an object to the array instead of chaining two messages.

rebo
+1 I like this example of readability more than most of the ones when people argue about dots and brackets. I generally use the brackets and find them easier to read 90% of the time but this is good examples of cases where they aren't so easy to read.
Toby