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: Jens Alfke <email@hidden>
- Date: Tue, 07 Apr 2015 12:33:27 -0700
> On Apr 7, 2015, at 11:55 AM, Quincey Morris <email@hidden> wrote:
>
> The problem is that this approach doesn’t actually work, not in this form. There’s a little bit of Doing It Wrong™, but mostly this is pretty badly broken in Cocoa.
What Quincey said. I banged my head against this a lot back in 2005 or so and gave up on this approach. It sounds lovely — I can expose this property as an NSArray in my class’s public API even though it’s not really implemented as an NSArray! — but it just doesn’t work, not unless you make all of your’ class’s clients use
[myInstance valueForKey: @“myDatumList”]
instead of
myInstance.myDatumList
Yuck.
I first tried to work around this by wrapping that in a property:
- (NSArray*) myDatumList {
return [self valueForKey: @“myDatumList”];
}
As you might guess, this causes an infinite regress and crashes. :(
Then I tried to get clever and give the public property a different name from the one with the -countOf and …atIndex methods:
- (NSArray*) myPublicDatumList {
return [self valueForKey: @“myDatumList”];
}
The problem with this is that the .myPublicDatumList property isn’t KV-observable since the actual changes are happening to myDatumList instead. But if you don’t need the property to be mutable, this might be good enough for you…
—Jens
_______________________________________________
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