1. Welcome to the new MacRumors forums. See our announcement and read our FAQ

How does new ObjC 2.0 properties accessors work?

Discussion in 'Mac Programming' started by zippyfly, Mar 29, 2008.

  1. macrumors regular

    So I am reading the new ObjC 2.0 docs:


    And come across

    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)?
  2. macrumors 68030


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

    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];
  4. macrumors 68040


    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.

  5. macrumors 6502a


    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.
  6. macrumors 601


    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.
  7. macrumors 68040


    I feel it is my duty to come along and say:

    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.

  8. macrumors 68030


    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.
  9. macrumors 65816


    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.
  10. macrumors 68040


    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.
  11. macrumors 601


    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.
  12. macrumors 68030


    This may or may not be fixed in a future Xcode version, btw ;)
  13. Moderator emeritus


    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.

Share This Page