> On 8 Apr 2015, at 3:58 am, Daryle Walker <[email protected]> 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 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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [email protected]
