iOS Dot operator vs []

[reputationZed]

Wirelessly posted (Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_3_3 like Mac OS X; en-us) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8J2 Safari/6533.18.5)

I've played around with C, C++, java that I'm fairly comfortable with the . operator, but I'm more than willing to give [] a go, as the references I'm using to learn Objective C follow that convention. I don't know if this has reached the level of religious war but I'd like to here some feedback.

 

[Avicenna]

I use []. It keeps my C code separated from ObjC. But it all comes down to personal preferences, I puke when I see dot operator being used, but I see it most of the times in sample code...

Also, kinda off topic, but I hate it when I see open parenthesis on the next line rather than the same. For example people doing:

- (void)foo
{
//hate this
}

rather than

- (void)foo {
//this looks much cleaner to me
}

 

[Luke Redpath]

As a general rule of thumb, dot notation is best reserved for properties or property-like accessors (queries). Square brackets should be used for commands. or any methods that require parameters.

The Google Objective-C style guide is pretty decent; I think Apple have some coding conventions somewhere too.

http://google-styleguide.googlecode.com/svn/trunk/objcguide.xml

I try not to get hung up about coding conventions.

I have my own preferences (2 spaces for indents, no hard tabs, method opening brace on a new line, NSString *foo not NSString* foo etc.) but the most important thing is consistency, especially if you are working on a team or on open-source projects with multiple contributors; you need to be flexible and willing to use different conventions when necessary.

The only thing that really bothers me is inconsistent or over-spacing, e.g.:

- ( id ) doSomething : (NSString *var) withThis 
{}

as opposed to:

- (id)doSomething:(NSString *var)withThis
{}

 

[robbieduncan]

The . operator to call methods only works for declared properties and is simply syntactic sugar that is expanded by the compiler to the "correct" accessor method call in [ ] anyway.

 

[Luke Redpath]

The . operator to call methods only works for declared properties

Nope, it works for any method that doesn't take arguments; a surprising number of people don't seem to realise this. Like you said, it's just syntatic sugar so "foo.bar" will turn into "[foo bar]" - it doesn't matter if 'bar' is a property or just a method.

 

[robbieduncan]

Nope, it works for any method that doesn't take arguments.

My mistake. In that case the above is more of a personal stylistic thing. I only use it for properties. That may be because I believe that was all it worked for though

 

[Luke Redpath]

My mistake. In that case the above is more of a personal stylistic thing. I only use it for properties. That may be because I believe that was all it worked for though

I use it for anything that could conceivably be a property (but may not be because, for instance, it's an old API). Basically, anything that accesses state rather than invokes behaviour.

This article describes the intention of dot notation well:
http://eschatologist.net/blog/?p=160

 

[amorya]

I use []. It keeps my C code separated from ObjC. But it all comes down to personal preferences, I puke when I see dot operator being used, but I see it most of the times in sample code...

Also, kinda off topic, but I hate it when I see open parenthesis on the next line rather than the same. For example people doing:

- (void)foo
{
//hate this
}

rather than

- (void)foo {
//this looks much cleaner to me
}

Now there's a religious war!

I'm firmly on the other side. If the braces are on their own lines, then the opening and closing brace of a block line up in a column, so you can tell which is which more easily.

Also, the other style only came about to save paper when printing a book, rather than for any sensible on screen use

 

[jared_kipe]

Now there's a religious war!

I'm firmly on the other side. If the braces are on their own lines, then the opening and closing brace of a block line up in a column, so you can tell which is which more easily.

Also, the other style only came about to save paper when printing a book, rather than for any sensible on screen use

I would argue that as long as you keep your code properly indented, it is just as easy to see where stray brackets and braces don't line up.

 

[ViviUO]

Also, kinda off topic, but I hate it when I see open parenthesis on the next line rather than the same. For example people doing:

- (void)foo
{
//hate this
}

rather than

- (void)foo {
//this looks much cleaner to me
}

Oddly enough, I feel the same way, except in CSS where i prefer it this way:

#blahblah
{
color: #000000;
}

 

[Guiyon]

Nope, it works for any method that doesn't take arguments; a surprising number of people don't seem to realise this. Like you said, it's just syntatic sugar so "foo.bar" will turn into "[foo bar]" - it doesn't matter if 'bar' is a property or just a method.

I'm guessing this is only because GCC does the rewriting before actually spitting out the compiled code. IIRC, I don't believe this works when using Clang; it actually spits out an error that property 'x' is not defined.

 

[Luke Redpath]

I'm guessing this is only because GCC does the rewriting before actually spitting out the compiled code. IIRC, I don't believe this works when using Clang; it actually spits out an error that property 'x' is not defined.

It works fine with LLVM (including 3.0).

 

[NickFalk]

A good argument against dot-notation in Objective-C is that it might look like you’re using a C-struct rather than sending a message to an object. I also prefer square-brackets as I find it gives a quicker overview of where I’m using Objective-C and working on my custom objects rather than Procedural-C and regular variables etc.

 

[Luke Redpath]

A good argument against dot-notation in Objective-C is that it might look like you’re using a C-struct rather than sending a message to an object.

I don't think that's a good argument at all. Most of the time you're *not* going to be using a struct and when you are (CGRect etc.) it should be obvious by it's context.

 

[jiminaus]

A good argument against dot-notation in Objective-C is that it might look like you’re using a C-struct rather than sending a message to an object. I also prefer square-brackets as I find it gives a quicker overview of where I’m using Objective-C and working on my custom objects rather than Procedural-C and regular variables etc.

I too have this reservation about the dot notation. That is, that someone might think it's a cheap operation, when in fact it's not.

Having said that, dot notation really can make some code much more readable, particularly when following chains of objects. And it's the same style as is used in Key-Value Binding.

Personally I'm undecided, and end up using it inconsistently.

And to add to side-war on braces. I use both. Why? I like to use whitespace to clarify syntax for overloaded tokens. For example, the three uses of asterisk.

Type* // Asterisk at the end of a word is pointer asterisk
*var // Asterisk at the start of a word is dereferencing asterisk
a * b // Asterisk by itself is multiplication asterisk

I do the a similar thing with braces. Braces defining compiler entities (such as classes, struct, methods and functions) verses braces delimited code blocks (such as after if, when, switch).

void myfunc()
{
   // Blah
   if (condition) {
     // Blah
   }
}

 

[NickFalk]

I don't think that's a good argument at all. Most of the time you're *not* going to be using a struct and when you are (CGRect etc.) it should be obvious by it's context.

You’re probably right, but I still think it messes things up when the same syntax can mean completely different things. Also when you’re scanning through code you haven’t read in a while I won’t stop looking at the dots if I’m looking for something done to an object. This can be a timesaver.

If you’re using mostly procedural-C (not unlikely if you want to use your code outside Apple’s playground as well) you might setup something like a spaceship struct for a simple game. If you’re doing it with Objective-C you’ll probably define a class.

spaceship.x = 200; // Can be either one
 
[spaceship setX:200]; // Should be obvious

 

[amorya]

My own convention for dot syntax:

I only use it for properties. I make sure that all my properties are conceptually values that are set and returned —*changing one should never do anything computationally intensive or have wider ramifications. (That's not to say I never override the synthesized setters — I do, for things like when one property is dependent on another. But I never fire off long operations or do unexpected things in them.)

I find it makes the code look cleaner, and I like separating methods which do stuff from methods which set stuff.

The article posted above about when to use properties is pretty good. It sums up what I try to do. (Not that my style is 100% consistent or perfect!)

 

[jared_kipe]

I don't really see the problem with people confusing object dot syntax and struct dot syntax, AS LONG AS you are using object dot syntax as it is initially prescribed.

foo.bar = 10;

If you use the dot syntax only for getters and setters it doesn't matter if foo is a struct or an object, the meaning is the same.

foo.bar = someNSArray;

This is slightly more confusing, but the basic idea is the same if foo is an object or a struct. The behavior of struct is the same as if its an object with the @property assign.

My point is in the first situation it doesn't really matter, and in the second situation the syntax is a little cloudy, and you should find out if its an object and what @property's it's using.

 

[NickFalk]

I don't really see the problem with people confusing object dot syntax and struct dot syntax, AS LONG AS you are using object dot syntax as it is initially prescribed.

foo.bar = 10;

If you use the dot syntax only for getters and setters it doesn't matter if foo is a struct or an object, the meaning is the same.

Yes, foo can be either a c-struct (normally cheap) or an Objective-C object (more expensive). Sorry, but I have a really hard time understanding why this ability to confuse the two is a good thing?

 

[Luke Redpath]

Yes, foo can be either a c-struct (normally cheap) or an Objective-C object (more expensive). Sorry, but I have a really hard time understanding why this ability to confuse the two is a good thing?

I don't think anybody is saying that, just that most of the time, there isn't any confusion as the context *usually* makes it obvious what you are dealing with.

 

[NickFalk]

I appreciate the ideas behind the article linked above, and agree that in most cases the struct/Object.property problem should be easily avoided. I would think most people here would agree that code should be as clear to read as possible and I personally don’t think that the dot-syntax in ObjC helps. I also like the fact that traditionally ObjC-code shows itself immediately, so that it’s fairly obvious where the Procedural-C ends and the Objective bit starts.

But this is perhaps, as others have mentioned, closer to religion than anything else.

 

[jared_kipe]

Yes, foo can be either a c-struct (normally cheap) or an Objective-C object (more expensive). Sorry, but I have a really hard time understanding why this ability to confuse the two is a good thing?

[someObject setValueX: (NSObject *) otherObject];

How expensive is this operation??

Well that depends on a lot of things. If it is a very very simple wrapper (like @property(nonatomic, assign) would give you), then I would argue that it is negligibly more expensive than a c-struct's assignment.

On the other side of the spectrum you could have a setter that is like @property(atomic, copy) which depends a LOT on the implementation of otherObject's Class.

Could it be worse?

ABSOLUTELY!!!
At least with @properties there is a general expectation of "how expensive" an getter or setter would be. But you could have written -setValueX: to so some heavy calculations or drawing based on the setting of the new value.

Bottom line, at least for me, is that dot property syntax in Objective-C 2.0, at least as implemented by default, gives you about as much information about the "operation" you could get without knowing substantially more about the implementation of the class or methods.

 

[firewood]

A good argument against dot-notation in Objective-C is that it might look like you’re using a C-struct rather than sending a message to an object.

Unless you override a property, or are doing key-value observing, you are using a C-struct, the one backing the Objective-C object. You're just sending that object a getter/setter message to access some bits inside that C-struct for you, and wasting some of your app's user's battery life by executing a longer machine code path to do so.

The more I have to scroll, the more I forget the source code I just read. So I use whatever syntax and code style works to fit the source code I need to see on one screenful of an editor pane, with enough whitespace to make it cleanly readable. This tends to be a bit more terse now that I'm primarily coding on an MBA 11, so I'm using a bit more dot notation. But, even so, using dot notation for calling parameterless methods looks too strange for me.