On Sep 23, 2011, at 6:06 PM, Greg Parker wrote:

> On Sep 23, 2011, at 3:47 PM, Charles Srstka wrote:
>> On Sep 23, 2011, at 5:24 PM, Jerry Krinock wrote:
>>> When creating a new project in Xcode 4.1, I get a window which is declared 
>>> in the app delegate as:
>>> 
>>> @property (assign) IBOutlet NSWindow *window;
>>> 
>>> and defined as
>>> 
>>> @synthesize window ;
>>> 
>>> Is this not going to create unnecessary unnecessary setter and getter 
>>> implementations?  Would not @dynamic be more appropriate in this situation?
>> 
>> Seems to me like a setter is the better way for an outside class (like 
>> NSBundle, NSNib, etc.) to set the outlet properties on the owner object. I 
>> know this used to work directly with ivars in the old days, but I’m still 
>> puzzled as to exactly how that worked. Was NSBundle really breaking 
>> encapsulation somehow and fiddling with objects’ ivars directly?
> 
> KVC first looks for a method with an appropriate name. If no method is found, 
> it looks for an ivar with an appropriate name. If it finds an ivar but no 
> accessor method, it will access the ivar directly. The Objective-C compiler 
> and runtime provide enough metadata to inspect and manipulate an object's 
> ivars.
> 
> Nib connection on iOS uses KVC. Nib connection on OS X does not use KVC 
> itself, but it does use a similar "call method if it exists, set ivar 
> directly if it does not" algorithm.

But how does that work? If I make the IBOutlet an ivar, make it @private, and 
have +accessInstanceVariablesDirectly return NO, trying to access this ivar 
directly from another object causes a compiler error, and trying to access it 
via KVC throws a “not key value coding-compliant for the key <outlet name>” 
exception. Yet the nib loading mechanism is still able to set the ivar. I’ve 
always been curious about why exactly this works.

Charles_______________________________________________

Cocoa-dev mailing list ([email protected])

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 [email protected]

Reply via email to