> On May 20, 2015, at 1:04 PM, Alex Zavatone <z...@mac.com> wrote: > > In the code I've inherited, I've got the benefit of spending some time > refactoring and have an interesting situation. > > Many times in the classes, an ivar is defined in the @interface of the class. > Sometimes not. Then sometimes, the same name of the ivar is used in the > class and defined as a property and @synthesized. > > Sometimes not. > > Sometimes, the ivars and properties start with lowercase letters as intended. > Sometimes not. > > Now, I remember back in 2012 that I could access a property within an > instance of the object without using self, but never knew if I was accessing > the ivar or the property itself simply by looking at the object. > > Sure, if there was a 'self.' in front of the object instance, I knew it was > the property. But in the case(s) I have today, I'm looking at inconsistently > cased instance variables (some properties) and nowhere are any preceded by > 'self.' within the object instance, yet in the debugger's variable pane, > these variables that look like ivars are all under listed under self. > > Wha? > > Which are they, ivars or properties? > > I don't know. I can't tell. > > Is there any way to inspect an instance and tell if it is a property or an > ivar if both the property and ivar have the same name?
By default a property creates an ivar, the name of which depends slightly on if you are relying on auto-synthesis (in which case property foo creates ivar _foo) or explicit synthesis (in which case property foo creates ivar foo, which explains your “I didn’t need self” remembrance). Explicit synthesis can also provide a different ivar name, the only way to know what the ivar is named is to look for the @synthesize directives. Finally you can have a property that is not backed by an ivar at all, which would mean if you have property foo, you have -foo and -setFoo: accessors that don’t use the ivar at all (assuming you don’t also have an @synthesize; in that case it is probably just a bug). > > Fun times, fun times. > > Thanks in advance. > > - Alex Zavatone > > > _______________________________________________ > > 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: > https://lists.apple.com/mailman/options/cocoa-dev/david.duncan%40apple.com > > This email sent to david.dun...@apple.com -- David Duncan _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
