On Apr 7, 2015, at 2:33 PM, Jens Alfke <[email protected]> wrote:
>
> 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…
Does this not work?
+ (NSSet *)keyPathsForValuesAffectingValueForMyPublicDatumList {
return [NSSet setWithObject:@“myDatumList”];
}
Charles
_______________________________________________
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]
