<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Objective-C 2.0 Properties Are Needlessly Verbose</title>
	<atom:link href="http://joeygibson.com/2008/12/28/objective-c-20-properties-are-needlessly-verbose/feed/" rel="self" type="application/rss+xml" />
	<link>http://joeygibson.com/2008/12/28/objective-c-20-properties-are-needlessly-verbose/</link>
	<description>Java, Clojure, Scala, Groovy, Ruby, Python, Lisp, Objective-C, OSX, politics, religion, Koine Greek, Tae Kwon Do, Spanish and much more!</description>
	<lastBuildDate>Fri, 27 Jan 2012 16:22:41 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=</generator>
	<item>
		<title>By: Clint</title>
		<link>http://joeygibson.com/2008/12/28/objective-c-20-properties-are-needlessly-verbose/comment-page-1/#comment-787</link>
		<dc:creator>Clint</dc:creator>
		<pubDate>Thu, 05 Feb 2009 23:54:02 +0000</pubDate>
		<guid isPermaLink="false">http://joeygibson.com/?p=898#comment-787</guid>
		<description>Good post! I, too, had a tough time getting the &quot;ivar=implemenation detail, @property=interface, @synthesize=link between them&quot; concept through my head. Something that really helped me understand it, though, was seeing how to use properties with ivars when their names don&#039;t match.

Note in the following example that the ivars use underscore prefix (which makes them easy to discern from other, non-ivar variables):
&lt;code&gt;
@interface MyClass : NSObject {
@private
    // Private ivar needs getter/setter to be accessible
    UITextField *_textField;
}
// Note that the property name does NOT have the underscore prefix
@property (nonatomic, retain) IBOutlet UITextField *textField;
&lt;/code&gt;

This shows how the @synthesize tag is the &quot;bridge&quot; that connects the ivar to the property (i.e., automatic method generation):
&lt;code&gt;
@implementation
...
// Generate textField: and setTextField: methods for _textField ivar
@synthesize textField=_textField;
...
@end
&lt;/code&gt;

As another sidenote (similar to Ahruman&#039;s), it&#039;s interesting to note that the IBAction &quot;type qualifier,&quot; like IBOutlet, is also pre-processor macro defined by UIKit in UINibDeclarations.h:
&lt;code&gt;
#ifndef IBAction
#define IBAction void
#endif
&lt;/code&gt;

This means that &lt;code&gt;- (IBAction)someMethod:(id)sender;&lt;/code&gt; gets turned into &lt;code&gt;- (void)someMethod:(id)sender;&lt;/code&gt;.</description>
		<content:encoded><![CDATA[<p>Good post! I, too, had a tough time getting the &#8220;ivar=implemenation detail, @property=interface, @synthesize=link between them&#8221; concept through my head. Something that really helped me understand it, though, was seeing how to use properties with ivars when their names don&#8217;t match.</p>
<p>Note in the following example that the ivars use underscore prefix (which makes them easy to discern from other, non-ivar variables):<br />
<code><br />
@interface MyClass : NSObject {<br />
@private<br />
    // Private ivar needs getter/setter to be accessible<br />
    UITextField *_textField;<br />
}<br />
// Note that the property name does NOT have the underscore prefix<br />
@property (nonatomic, retain) IBOutlet UITextField *textField;<br />
</code></p>
<p>This shows how the @synthesize tag is the &#8220;bridge&#8221; that connects the ivar to the property (i.e., automatic method generation):<br />
<code><br />
@implementation<br />
...<br />
// Generate textField: and setTextField: methods for _textField ivar<br />
@synthesize textField=_textField;<br />
...<br />
@end<br />
</code></p>
<p>As another sidenote (similar to Ahruman&#8217;s), it&#8217;s interesting to note that the IBAction &#8220;type qualifier,&#8221; like IBOutlet, is also pre-processor macro defined by UIKit in UINibDeclarations.h:<br />
<code><br />
#ifndef IBAction<br />
#define IBAction void<br />
#endif<br />
</code></p>
<p>This means that <code>- (IBAction)someMethod:(id)sender;</code> gets turned into <code>- (void)someMethod:(id)sender;</code>.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: joeygibson</title>
		<link>http://joeygibson.com/2008/12/28/objective-c-20-properties-are-needlessly-verbose/comment-page-1/#comment-746</link>
		<dc:creator>joeygibson</dc:creator>
		<pubDate>Sun, 28 Dec 2008 20:13:13 +0000</pubDate>
		<guid isPermaLink="false">http://joeygibson.com/?p=898#comment-746</guid>
		<description>Thanks for the info, Ahruman. There&#039;s a lot there that I didn&#039;t know.</description>
		<content:encoded><![CDATA[<p>Thanks for the info, Ahruman. There&#8217;s a lot there that I didn&#8217;t know.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ahruman</title>
		<link>http://joeygibson.com/2008/12/28/objective-c-20-properties-are-needlessly-verbose/comment-page-1/#comment-745</link>
		<dc:creator>Ahruman</dc:creator>
		<pubDate>Sun, 28 Dec 2008 20:05:32 +0000</pubDate>
		<guid isPermaLink="false">http://joeygibson.com/?p=898#comment-745</guid>
		<description>The fundamental reason is that the ivar and the property are separate entities. The property is part of the class’s interface, while the ivar is an implementation detail, as is the connection between them expressed by the &lt;code&gt;@synthesize&lt;/code&gt; directive. It is a fundamental, er, property of properties that you can change their implementation (or override it in a subclass) without changing the interface.

This points at a wart in Objective-C: the ivars of a class are (generally) implementation details, but are part of the &lt;code&gt;@interface&lt;/code&gt; block. This is because, in the traditional Obj-C runtimes, ivars were accessed as fixed offsets from the &lt;code&gt;self&lt;/code&gt; pointer, meaning that subclass implementations had to know about the ivar layouts of their superclasses which thus had to be public.

This is fixed in the new non-fragile runtime, as used in 64-bit Mac OS X apps and all iPhone apps. When targeting the new runtime, you don’t need the ivar declaration (as long as you don’t access the ivar directly), and just need the &lt;code&gt;@property&lt;/code&gt; declaration in the &lt;code&gt;@interface&lt;/code&gt; block and the &lt;code&gt;@synthesize&lt;/code&gt; directive in the &lt;code&gt;@implementation&lt;/code&gt; block (or an explicit implementation not using an ivar, or &lt;code&gt;@dynamic&lt;/code&gt;).

The wart still exists, since you can’t declare ivars in the &lt;code&gt;@implementation&lt;/code&gt; block in the non-fragile runtime except for synthesized ivars. Feel free to dupe &lt;a href=&quot;http://openradar.appspot.com/5581983&quot; rel=&quot;nofollow&quot;&gt;my bug&lt;/a&gt; on the issue.

As a side note, &lt;code&gt;IBOutlet&lt;/code&gt; isn’t really ignored by the parser; it’s an empty preprocessor macro, so it’s removed before anything Obj-C-specific sees it.</description>
		<content:encoded><![CDATA[<p>The fundamental reason is that the ivar and the property are separate entities. The property is part of the class’s interface, while the ivar is an implementation detail, as is the connection between them expressed by the <code>@synthesize</code> directive. It is a fundamental, er, property of properties that you can change their implementation (or override it in a subclass) without changing the interface.</p>
<p>This points at a wart in Objective-C: the ivars of a class are (generally) implementation details, but are part of the <code>@interface</code> block. This is because, in the traditional Obj-C runtimes, ivars were accessed as fixed offsets from the <code>self</code> pointer, meaning that subclass implementations had to know about the ivar layouts of their superclasses which thus had to be public.</p>
<p>This is fixed in the new non-fragile runtime, as used in 64-bit Mac OS X apps and all iPhone apps. When targeting the new runtime, you don’t need the ivar declaration (as long as you don’t access the ivar directly), and just need the <code>@property</code> declaration in the <code>@interface</code> block and the <code>@synthesize</code> directive in the <code>@implementation</code> block (or an explicit implementation not using an ivar, or <code>@dynamic</code>).</p>
<p>The wart still exists, since you can’t declare ivars in the <code>@implementation</code> block in the non-fragile runtime except for synthesized ivars. Feel free to dupe <a href="http://openradar.appspot.com/5581983" rel="nofollow">my bug</a> on the issue.</p>
<p>As a side note, <code>IBOutlet</code> isn’t really ignored by the parser; it’s an empty preprocessor macro, so it’s removed before anything Obj-C-specific sees it.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

