Re: Stupid Cocoa question. How can you tell if the object you are looking at is a property or an ivar?
Re: Stupid Cocoa question. How can you tell if the object you are looking at is a property or an ivar?
- Subject: Re: Stupid Cocoa question. How can you tell if the object you are looking at is a property or an ivar?
- From: Alex Zavatone <email@hidden>
- Date: Thu, 21 May 2015 12:28:07 -0400
Ahh. A little follow up.
One area we all know about is that you can specialize the name of the property's ivar like so:
@synthesize thing = _thing;
Which makes the internal and private ivar to be _thing while the property becomes thing.
In my case, this helps to uncover where the original code is accessing the ivar as opposed to the property.
Instantly, as soon as you manually synthesize this way, the compiler points out every case in the class where the instance name is no longer valid.
The problem behind this all is that if you use self.myThing, that's obviously a property, but if you use myThing, it's not visually obvious that you're directly accessing the ivar, not the property. When Xcode creates your properties with auto-synthesis, the compiler appears to create an ivar with the same name as property. Within the class itself, you can access self.myThing and myThing interchangeably and they will both end up with the same value as expected. Unfortunately, this makes it not visual no brainer which one you're accessing unless you pay attention.
In my case, the wonderful original programmers created the instance variables and properties with the same name and frequently accessed both as if they were one and the same, resulting in some rather dense code.
In an effort to refactor the code for readability and clarity, going through each class and making this change makes it painfully clear when the ivar's being accessed and when the property is.
The reason why this matters is when trying to refactor code like this if you have ivars and properties declared with the same name, Xcode's refactoring fails if you try to refactor the property first. At least in my case, it does.
In the effort to put some clarity into our large-ish classes, refactoring the ivars first means that I have to identify where they are used and using this @synthesize approach allows that.
Now that I have a path forward and understand why things are what they are, this brings up the wonderful speed issue of "how much slower is property access vs ivar access". Whichever you use depends on just how much you need speed vs encapsulation. Thankfully, that difference is summarized in charts at the end of the link below.
https://www.bignerdranch.com/blog/should-i-use-a-property-or-an-instance-variable/
Again, thanks all who took their time to provide the backing information on this for me.
Cheers,
Alex Zavatone
On May 21, 2015, at 9:45 AM, Alex Zavatone wrote:
>
> On May 20, 2015, at 7:16 PM, Michael David Crawford wrote:
>
>> You could comment off their declarations in your header files, then
>> have a look at which uses of them in your sources result in fatal
>> compiler errors.
>
> Bingo. That will do it.
>
> Thanks much to everyone on this. It's certainly gotten me a little more in touch with the guts of this all.
>
> Alex Zavatone
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> 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:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden