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: Daryle Walker <email@hidden>
- Date: Tue, 07 Apr 2015 13:58:36 -0400
> On Apr 6, 2015, at 10:18 PM, Graham Cox <email@hidden> wrote:
>
>>
>> On 7 Apr 2015, at 12:01 pm, Daryle Walker <email@hidden> wrote:
>>
>> I have an object like:
>>
>> @interface MyClass : NSObject
>> @property (readonly) NSArray * myDatumList;
>> @property NSArray * myDataList;
>> @end
>>
>> The second member is meant to be an actual data member, an array of mutable dictionaries. The first member isn’t supposed to have a backing store; accessing a member of the first array references the corresponding member of the second, then access a dictionary attribute with a custom key.
>>
>> I have a custom array count and array element read methods for the first member.
>>
>> The program does nothing now. I checked with my limited debugging skills that the second member has one element, but the first member is looped though as if it has no elements. I see that BOTH “_myDatumList” and “_myDataList” internal members exist, with the former set as NIL. I’ve heard that we used to need to use the “@synthesize” command to create internal members, then a later version of the Objective-C compiler did it automatically. Now I have the reverse problem; the first member gets a backing store automatically, but I do NOT want that; I always want to use the custom array accessor methods to simulate “myDatumList” with pieces of “myDataList.”
>>
>> So, how can I turn off auto-@synthesize? Using “@dynamic” doesn’t work; it causes a crash due to a missing [MyClass myDatumList] method. I also saw a random page saying that “self.myDatumList” causes this, but “myDatumList” wouldn’t (like the “self.” gives the unwanted backing store have priority over the array accessor methods). Is that accurate?
>
>
>
> You need to write your own getter method for myDatumList, and write the code in there to do what you want it to do. Since it's a readonly property, the compiler will be satisfied that you've done everything necessary to implement the property and won't give it any backing store at all.
>
> As a general comment, I personally find the automatic creation of backing store by default leads to bugs and confusion - how it was originally with the requirement to either use @synthesise and/or write your own methods was cleaner and less bug-prone, even if it did add a tiny bit of extra work. C'est la vie…
I already have:
@implementation MyClass
// @synthesize myDataList = _myDataList; // Not really needed due to auto-@synthesize
- (NSUInteger)countOfMyDatumList {
return self.myDataList.count;
}
- (id)objectInMyDatumListAtIndex:(NSUInteger)index {
NSDictionary * const dict = self.myDataList[index];
return dict[@“datum”];
}
@end
Do I have to switch to a “- (NSArray *)myDatumList” method? If so, do I also use “@dynamic myDatumList”?
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?
…
OK, using @dynamic suppresses the creation of backing ivars, for both the BOOL and the NSArray. I got around the crash for the simulated array property by using a direct getter. So the bug is that @dynamic always looks for a direct getter, even for collection-based properties. (It never considers a countOf… / objectIn…AtIndex pair.)
Radar #20451913
—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com
_______________________________________________
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