On Sep 19, 2010, at 1:11 PM, Markus Spoettl wrote: > One thing you get is automatic KVO change notifications. When you set a > property through its setter, you don't have to use -willChangeValueForKey: > and -didChangeValueForKey: in order to trigger -observeValueForKeyPath: > messages for those objects observing the property (via -addObserver:).
You'd get that anyway. The point of @property was to capture getters and setters into a single syntactic unit such that it is easy to see exactly what should be treated as a property/attribute/data-thingy on any given class. But not just that the set/get methods exist, but: - the memory management policy is now declarative in the interface - atomic vs. nonatomic is declarative - setter/getter can be mapped to other methods (getter=isEnabled, for example) - synthesis "just works" (pretty much every attempt at hand-rolled atomicity I've seen has been wrong or bog slow) - the IDE can deduce additional details of your code based on declaration (code-sense prefers properties on the RHS of a dot, for example) - minimize lines of code That last point has been achieved in stages. In the move to the modern Objective-C 2.0 ABI (the runtime you get on iPhone and 64 bit Mac OS X), you don't need to declare iVars for @property()s as the compiler will synthesize the storage, too. In llvm 2.0 top-of-tree, @synthesize is on by default for all @properties. Thus, with the latest bleeding edge compiler, all you need is the @property() (and cleanup in -dealloc) to declare a fully KVO compliant attribute of your class. The dot is syntactic convenience and pretty much nothing more. The dot does enforce more compiler checking than regular method invocations, though (can't use dot w/id and the compiler will whine if you use the dot in a non setter/getter role). b.bum (Who is still on the fence as to whether the dot was a good idea; it sure does cause confusion, but damned if it isn't awfully convenient. Sigh.) _______________________________________________ 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
