PDA

View Full Version : Is the dot notation supported in OSX 10.6- ?




printz
May 13, 2013, 03:22 AM
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?



gnasher729
May 13, 2013, 05:56 AM
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?

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".

Guiyon
May 13, 2013, 11:02 AM
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?

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.

ArtOfWarfare
May 13, 2013, 11:08 AM
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.

gnasher729
May 13, 2013, 11:24 AM
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.

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.

Guiyon
May 14, 2013, 10:47 AM
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.

gnasher729
May 14, 2013, 10:55 AM
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.

ArtOfWarfare
May 14, 2013, 11:16 AM
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.

Sydde
May 14, 2013, 02:08 PM
@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:
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.)