In Xcode 4 I can say a.b instead of [a b] (when selector b has no arguments). I've been getting warnings and errors when trying to compile this with Xcode 3 on OSX Snow Leopard, but not everywhere I used dots. Shall I consider that if I want to make my code compilable in 10.6 and below, I should only use bracket notation?
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
macOS Is the dot notation supported in OSX 10.6- ?
- Thread starter printz
- Start date
- Sort by reaction score
It's not a matter of the operating system where you want to run your code, but of the Xcode version that you are using. In some earlier Xcode versions dot notation only worked for things that were explicitly declared as properties. In new versions, it also works when you have just the setter and getter methods declared.
There are other differences; in old Xcode versions you get a warning when you use a method that is declared later.
So the answer: No, you don't need to use brackets notation. Look at the warning and fix what it says. You may have to declare a property, you may have to add an "interface" with missing declarations in front of your "implementation".
If it's not a declared property, don't use dot notation - period. The fact that it works in some situations is not documented behavior and should not be relied upon.
Just going to throw this out here: properties need not be backed by iVars. I often make read only "properties" that, as a getter implementation actually perform a calculation and return that calculate value (instead of an iVar.)
IDK if that was obvious to everyone else, but I only started doing it a few weeks ago. It makes for a lot neater looking code, I think.
If it compiles, then it works - period. obj.property is compiled in exactly the same way as [obj property], and obj.property = value is compiled in exactly the same way as [obj setProperty:value]. No reason whatsoever to avoid this.
Common sense dictates that you use this for properties. NSMutableString* aString = NSMutableString.alloc.init works but is almost criminal.
I'm not saying it doesn't work and I'm not arguing that @property isn't syntactical sugar but just because it works *right now* doesn't mean it's right. Treating the dot operation outside of its expected use (accessing/mutating properties) is like depending on a private API; sure it works for now but you're just asking for the rug to be pulled out from under you.
Well, no. I said "if it compiles then it works". That's something you can rely on. If it ever breaks (which is highly, highly unlikely), then the compiler will tell you. Software shipped to customers isn't going to break.
And there are plenty of getters/setters in Cocoa that haven't been declared as properties but that are in fact properties; there is no reason not to use dot accessors for them.
I agree with this. It'd be nice if Apple would formally declare them all as properties, though.
@property requires a method or methods to be accessible. The easy way to do this is with @synthesize, but otherwise you can easily code the method yourself. For example, you could consider length to be a property of NSString, even though it is not clear whether the value is stored or calculated. In fact, the following code works as one might expect:
Though, that one would use dot syntax with - init is highly dubious, it just points out that a method with no parameters that returns a value can use dot syntax. (I tried to write aString.string = @"words"; but my compiler would not accept that.)
Code:
NSMutableString *aString = [NSMutableString alloc];
aString = aString.init;
[aString setString:@"words"];
NSInteger itsLen = aString.length;Though, that one would use dot syntax with - init is highly dubious, it just points out that a method with no parameters that returns a value can use dot syntax. (I tried to write aString.string = @"words"; but my compiler would not accept that.)