On Sep 19, 2010, at 12:52 PM, Jim Thomason wrote: > I'm refactoring and updating a lot of my older code, and one of the > things I'm finally looking into is declaring things as properties. > > But...what's the point? I've been trying to read up on the subject and > have found a lot of posts and discussion about the subject, but very > little of it seems to get down to the meat of what these things are > and why I should care about them. > > At the simplest level, I just look at them as some syntactic sugar.
Don't think of @property as syntactic sugar for declaring getter and setter methods. Think of @property as the way to declare the state exposed by an instance of a class, and methods as the way to declare the behavior exposed by an instance of a class. (Or the class itself.) > I know I'd get use of the dot syntax (I do need to use @properties to > do that, right?), but I'm eschewing it anyway. The same argument applies: Don't think of dot syntax as syntactic sugar for sending messages. Think of dot syntax as the way to access the state exposed by an object, and bracket syntax as the way to have an object do something. Yes, getting or setting state might “do something” behind the scenes, but conceptually you’re more getting or modifying some information “about” the object than treating it like an actor. This is part of why Xcode only offers dot syntax completions for properties declared via @property; it helps maintain the state versus behavior distinction. (Otherwise, it would offer completions like “.retain” and “.copy”.) -- Chris _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
