dot syntax vs method syntax with getter=

Question

I\'m not sure how much use this question is but it seems interesting to me...

I thought that using property/synthesize statements was equivalent to me creating the ge

Answer 1

However I am still unclear on where the "magic" wiring goes on that turns calls to myClass.on into [myClass isOn]

The logic surely goes as follows, when compiling an obj.name in a getting context:

if(there is an accessible @property for name in scope)
{
   if(there is a custom getter specified)
      compile "[obj customGetter]"
   else
      compile "[obj name]"
}
else if (there is an an accessible instance method name in scope)
   compile "[obj name]"
else
{
   compile "[obj name]"
   warn obj may not respond to name
}

There are other ways a language/execution environment can handle custom getter names, but given that Obj-C puts the declaration in the header (which is public) the above is a good guess as to where the custom getter logic is performed - when compiling the call site.

Answer 2

Well concerning dot notation, let me cite Aaron Hillegass (Cocoa Programming for Mac OSX, 3rd. Ed):

"Overall, I think that this is a rather silly addition to the language since we already had a syntax for sending messages."

When you have a member variable on, and your getter for this variable is called isOn then .on and .isOn are two very different kind of things. By using the getter (and probably a setter, too) you will adhere to the "information hiding" promise, whereas by using direct access to the member variables you won't. Cocoa won't enforce those things as it is relying on conventions. It's up to you to decide which way is right for you. Considering convention, you would have to stick to setters and getters - no matter what names you give them, though.

Answer 3

From your experiment we can infer that dot syntax is interpreted as follows:

• is there a property with this name? If so, does it have a specified getter / setter name? if so, let's call that method.
• otherwise, make up an appropriate method name (direct if we're getting, setXX if we're setting) and throw that at the receiver.

You can, for example, try to use .count against an NSArray instance. Before the abomination police kick in your doors, you may have time to see that it works.

To actually answer your question, in my mind dot notation should only be used to access properties, and in that case you should use the property name as declared in the interface. So .on for a UISwitch. I don't know why the getter name isn't given in the synthesize statement instead of the property declaration, it seems to belong in implementation rather than interface to me.

Answer 4

Property declarations are merely shorthand for regular method declarations. E.g.:

@property int color;
@property (getter=isOn) BOOL on;

becomes these method declarations:

- (int)color;
- (void)setColor:(int)value;
- (BOOL)isOn;
- (void)setOn:(BOOL)on;

You can call these methods just like any other method:

[foo color];
[foo isOn];

Likewise, dot notation is merely informal shorthand for calling plain old methods. For example:

x = @"Hello".length;
x = foo.on;
x = foo.isOn;

becomes

x = [@"Hello" length];
x = [foo isOn];
x = [foo isOn];

Note that @"Hello".length works even though NSString does not actually declare a property named "length". By default, foo.bar always expands to [foo bar] unless bar has been declared a property with a custom getter. If bar happens to be the name of a valid method then it will work without error.

Likewise, in your example foo.isOn works even though you don't actually declare a property named "isOn". Rather "isOn" is the name of a method that just happens to be the getter method for your "on" property.

So, while foo.isOn may work, it's considered bad form because isOn is not actually the name of the property.

What you cannot do is this:

x = [foo on]; // Error

because you never declare an on method.