> On Apr 6, 2015, at 10:18 PM, Graham Cox <graham....@bigpond.com> wrote: > >> >> On 7 Apr 2015, at 12:01 pm, Daryle Walker <dary...@mac.com> 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 (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com