Re: Making an array property without a backing store. How?
Re: Making an array property without a backing store. How?
- Subject: Re: Making an array property without a backing store. How?
- From: Graham Cox <email@hidden>
- Date: Wed, 08 Apr 2015 11:17:34 +1000
> On 8 Apr 2015, at 3:58 am, Daryle Walker <email@hidden> wrote:
>
> Looking at the debugger again, I noticed that my BOOL property with a custom getter (which simulates its result based on other member data) also has a “_myFlag” backing store. Is there some setting we’re missing, or do I have to file a bug to add no-auto-@synthesize?
>
Others have given you a much more complete answer than I did about -myDatumList, but just to pick up on this one.
I assume you've declared this something like:
@property (assign) BOOL myFlag;
But then implemented it something like:
- (BOOL) myFlag
{
return someOtherMemberData.flag;
}
Without any @synthesize for it.
The problem here is that the property is declared (assign). That means it's something that requires both a getter and a setter. So it has auto-synthesized the setter, as you only supplied the getter. In auto-synthesizing the setter, it has to provide backing store for it, hence _myFlag.
To fix that, you have a couple of options depending on what you need.
First, you could declare the property readonly. Then, the compiler knows no setter is required and won't synthesize one, and won't create backing store.
The other is to write the setter method as well. It could either set the indirect property, or just do nothing (though in the latter case that would be a readonly property, so you'd be better off declaring it as such).
As I mentioned, I feel that auto-synthesizing generally is somewhat evil. It adds code that you can't see and can't easily debug, and adds ivars that you can't see which may be masking (or masked by) other ivars that you might assume are the ones in use (if you forgot a corresponding @synthesize, which is an easy error to make since auto-synthesize covers it up). Since you can't turn off auto synthesizing, the next best thing is at least to enable the warning that it's done it: CLANG_WARN_OBJC_MISSING_PROPERTY_SYNTHESIS, shown as "Implicit Synthesized Properties" in the build settings.
Code that isn't magic is more readable, so for me declaring explicit ivars, writing getters, setters or @synthesize statements is always better than leaving it to invisible compiler magic, even if it adds a little more work. That small amount of extra work is easily repaid in time saved debugging an auto-synthesized ivar that you didn't even know was there. It has happened to me so many times now that I can usually find the problem quickly because I can smell the symptoms, but I feel for newbies to this stuff who have been misled into writing hard-to-debug code by something that really saves almost nothing in coding effort.
@property was a great improvement to Obj-C, but auto-synthesizing them was not. One of Apple's less useful design decisions, IMHO.
--Graham
_______________________________________________
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