views:

73

answers:

1

Hey guys, I just wrote a setter and getter method in apples format. There is no variable for it but I noticed I could use the dot syntax. Am I crazy? Does this actually work? Could someone explain exactly what lets you use the dot syntax?

// Here is my header definition. Keep in mind there is no class variable or @property for texture.
- (void)setTexture:(JGTexture*)texture;
- (JGTexture*)texture;

// Somewhere else using the dot syntax.
object.texture = tex;
+4  A: 

A property-access expression is equivalent to a message expression:

[object setTexture:tex];

A property declaration is equivalent to one (readonly) or two (readwrite/default) instance-method declarations. Keywords like retain tell the compiler how to implement the method if you tell it to do so (@synthesize).

However, you can skip the property declaration and declare the methods directly, as shown in your question. You can't synthesize their implementations, since you need a property declaration for that (otherwise, it wouldn't know what memory-management policy to use: assign, retain, or copy), but you can always implement the methods yourself.

Then, even though you declared and implemented the methods yourself, since property-access syntax and message syntax are equivalent to each other, you can use the methods whichever way you want: With a message expression, or with a property-access expression.

Some would consider it bad form, though, to use property access expressions on anything but a formal @property (e.g., myString.length or myArray.count or myView.frame). It definitely is bad form to use a property-access expression to send a message that doesn't access any kind of property; foo.retain.autorelease, for example, is bad and wrong: It reeks of trying to pretend you're programming some other language than Objective-C.

Incidentally, a property and a variable are unrelated. A @property will ordinarily be backed by an instance variable, but this is not required: You could store the property's value inside another object, or convert it to and from some other format, or both. Likewise, accessing a property (which is an accessor message) and accessing an instance variable (which is just accessing a variable, nothing more) are very different.

Peter Hosey
It accesses a specific index in an array of objects. Do you think this is bad form?
Justin Meiners
Generally, yes: The object should own the texture directly, not access a collection maintained by some other object. Suppose you delete one of the textures: Will these objects know that the indexes have shifted? Even if so, updating their indexes may be an unacceptable performance cost. Having them own their textures directly frees you of having to keep those relationships from breaking.
Peter Hosey
@Peter H.: you seem to have assumed that the object is interested in a particular texture, and not a particular index (whatever shows up at that index). So I would not assume it to be bad form without knowing more details about the relationship of interest.
hotpaw2
-1. While UIView.frame is a property, -[NSString length] and -[NSArray count] are not. I usually use property syntax anyway, since I think it's more clear, but pedants might not like it (and I'm not sure whether Objective-C guarantees that you can use property syntax without a corresponding property). Finally, properties can specify the underlying method name of the getter/setter; Apple seems to mostly use this for "isFoo" names. Obviously you need to declare a property if you want use property syntax with methods called isFoo/setFoo:.
tc.
tc.: I think you missed my point. I explicitly said that “Some would consider it bad form” to use property syntax on an informal property. You are right about `isFoo`; I don't think you could use `myObject.foo` to call the getter `isFoo` without a property to tell the compiler about the correspondence.
Peter Hosey
hotpaw2: True enough. Even if it is open to changes, though, shouldn't it be the controller's job to make those changes explicitly as they're warranted? In particular, missing indexes (those past the end of the array after objects at lesser indexes are deleted) are a potential cause of exceptions if not handled. Anything involving accessing some other object's array seems fragile to me.
Peter Hosey