> On Apr 7, 2015, at 11:55 AM, Quincey Morris
> <[email protected]> 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 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]
