macOS How does new ObjC 2.0 properties accessors work?

[zippyfly]

So I am reading the new ObjC 2.0 docs:

http://tinyurl.com/yvfz2s

And come across

Accessing Properties

Using the dot syntax, you can access a property using the same pattern as accessing structure elements.

MyClass *myInstance = [[MyClass alloc] init];

myInstance.value = @"New value";

NSLog(@"myInstance value: %@", myInstance.value);

The dot syntax is purely “syntactic sugar”—it is transformed by the compiler into invocation of accessor methods (so you are not actually accessing an instance variable directly). The code example above is exactly equivalent to the following:

MyClass *myInstance = [[MyClass alloc] init];

[myInstance setValue"New value"];

NSLog(@"myInstance value: %@", [myInstance value]);

And am confused.

If I do NOT write any setter/getter methods for the properties, can I just access them using dot notation? And if so, does the set/get code become automagically generated at compile time?

Or do I still write the set/get code, and the dot notation then defaults to using those methods, except that I can just type less (i.e., just the dot notation, rather than actually call the get/set methods)?

 

[Catfish_Man]

You can use @synthesize in the .m file to generate getters/setters.

 

[cazlar]

Yep, you just write @synthesize and they work "like magic". I believe you can override the setters/getters if you want but I've never had to. You can use the old [blah value] notation or the new blah.value notation interchangeably, though I find the newer one easier to follow when you have multiple nested accessors (eg object.shapes.triangle.colour is simpler to read than [[[object shapes] triangle] colour]).

And for setting, you just do
blah.value = newValue;
which is functionally equivalent and interchangeable with
[blah setValue:newValue];

 

[lee1210]

Just for kicks, to throw a dissenting view into the mix, I find the dot operator confusing and inelegant for accessing properties. I find message passes to be clearer, and allow for you to know immediately that you are dealing with an object *. Dot says to me that you're dealing with a local structure, -> says you're dealing with a structure *, and [x y] says you're passing a message to an object via an object *. Adding meaning to the ., in that it might be accessing a local structure member or it might be accessing the property on an object * just doesn't sit well with me. I think synthesizing accessors and mutators is great, there's no reason you should need to write them yourself, but I think using . to access them is an abomination.

I am well aware that many disagree with this sentiment, but I always make a point to put it out there because it pains me to look at code that uses it.

-Lee

 

[GorillaPaws]

Just for kicks, to throw a dissenting view into the mix, I find the dot operator confusing and inelegant for accessing properties.

...it pains me to look at code that uses it.

I feel the same way. I don't see the need to create redundancies in the grammar even if it does looks slightly prettier (an assertion which I'm still not convinced of).

[[[object shapes] triangle] colour]

Looks ok to me--it communicates the hierarchy in a more intuitive way, but I can appreciate that others like the dot-syntax better.

 

[HiRez]

Just for kicks, to throw a dissenting view into the mix, I find the dot operator confusing and inelegant for accessing properties. I find message passes to be clearer, and allow for you to know immediately that you are dealing with an object *. Dot says to me that you're dealing with a local structure, -> says you're dealing with a structure *, and [x y] says you're passing a message to an object via an object *.

I agree with you except I'm going to play the devil's devil's advocate and say that probably the majority of Cocoa programmers aren't doing much programming directly on structures. Whenever I find myself doing that I ask myself if I can make an object or entity out of that structure instead. Most of the time the answer is yes because, while perhaps requiring a little more upfront typing, it just makes things easier in this environment (like if you want to start stuffing those structures into an array, serialize them, use garbage collection, or whatever). For many applications operating on bare structures instead of objects doesn't bring you significant performance benefits on today's hardware (iPhone might be an exception here, I don't know). I realize that technically we're talking about Objective-C here and not Cocoa, but for all practical purposes we are talking about Cocoa.

Having said that I do think the dot syntax adds more confusion and doesn't add a huge benefit, so they probably should have just not gone there, especially since you can't call functions using it anyway, so you end up with an ugly mish-mash of the "old" and new syntax.

 

[lee1210]

I agree with you except I'm going to play the devil's devil's advocate and say that probably the majority of Cocoa programmers aren't doing much programming directly on structures. Whenever I find myself doing that I ask myself if I can make an object or entity out of that structure instead. Most of the time the answer is yes because, while perhaps requiring a little more upfront typing, it just makes things easier in this environment (like if you want to start stuffing those structures into an array, serialize them, use garbage collection, or whatever). For many applications operating on bare structures instead of objects doesn't bring you significant performance benefits on today's hardware (iPhone might be an exception here, I don't know). I realize that technically we're talking about Objective-C here and not Cocoa, but for all practical purposes we are talking about Cocoa.

Having said that I do think the dot syntax adds more confusion and doesn't add a huge benefit, so they probably should have just not gone there, especially since you can't call functions using it anyway, so you end up with an ugly mish-mash of the "old" and new syntax.

I feel it is my duty to come along and say:
NSPoint
NSRange
NSRect
NSSize

I realize these are foundation, but they make their way into a number of Cocoa methods. So even if you never define a struct, Apple has gone ahead and defined some for you that you won't be able to avoid.

This discussion is really all for naught. If someone likes the . notation they should use it, it's just a pet peeve of mine.

-Lee

 

[Catfish_Man]

The reason I use dot notation is to visually separate "work" from "OO boilerplate". Anything in square brackets (to the extent that syntax allows) is doing something. Whether the dot applies to a struct or object is frankly irrelevant to me.

 

[prostuff1]

I am a fan of the dot notation... but only as it applies to Java. I did/do most of my work in it so that notation is what I am use to and like looking at. Now that being said, why screw with something that does not need to be fixed. Sometimes giving people to many options will just cause more confusion. I say stick with the bracket notation and leave it at that.

 

[iSee]

I claim to be syntax-neutral and therefore do not prefer one over the other. I just want some amount of consistency for code-readability purposes.

Tie breaker: dot notation matches key path notation, so I'm going to go with dot notation when there's no countervailing readability issue.

 

[HiRez]

[[[object shapes] triangle] colour]

Looks ok to me--it communicates the hierarchy in a more intuitive way, but I can appreciate that others like the dot-syntax better.

One advantage with the dot syntax with nested messages is that you don't have to think ahead of time how many opening brackets you're going to need or go back and fix them later...I do that a lot. With dot syntax you just start at the beginning and keep adding on, there's no need to go back to balance out brackets.

 

[Catfish_Man]

One advantage with the dot syntax with nested messages is that you don't have to think ahead of time how many opening brackets you're going to need or go back and fix them later...

This may or may not be fixed in a future Xcode version, btw

 

[kainjow]

I like dot notation and use it with @properties whenever I can. Unfortunately I don't work on many 10.5 only projects but when I do it's easier on the eyes than brackets.