> On Apr 6, 2015, at 10:18 PM, Graham Cox <[email protected]> wrote:
>
>>
>> On 7 Apr 2015, at 12:01 pm, Daryle Walker <[email protected]> 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 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]
