On Jul 11, 2012, at 1:45 AM, Quincey Morris wrote: > **** There isn't AFAIK a really easy way to prevent clients that aren't > supposed to mutate the property from just invoking 'mutableArrayValueForKey: > @"<key>"' by themselves. > > One alternative approach is to use *two* property names: <privateKey> and > <publicKey>. > > You can then have <publicKey>'s getter return '[self valueForKey: > @"privateKey"]'. That solves the infinitely-recursing-getter problem, but > still returns an immutable observable proxy.
On Jul 11, 2012, at 1:55 AM, Quincey Morris wrote: > Ugh, that's not right. You have to generate the <publicKey> KVO notifications > manually in order to make the proxy properly observable. That means calling > suitable will/didChange… methods in suitable places. You can use +keyPathsForValuesAffecting<PublicKey> to make the public property emit KVO change notifications whenever the private property changes. However, I doubt that emits appropriate *array-specific* KVO change notifications for the public property – i.e. those whose change kind is NSKeyValueChangeInsertion, NSKeyValueChangeRemoval, or NSKeyValueChangeReplacement. Rather it will probably just emit whole-property-replaced (NSKeyValueChangeSetting) notifications. (By the way, you're using the term "proxy" in a manner which I find confusing.) Another approach is to just define a single property. Instead of implementing the KVC-compliant indexed accessor mutation methods, implement variants with a slightly non-conformant name (perhaps with a prefix of "private"). Then have those manually emit the proper KVO change notifications by invoking -will/didChange:valuesAtIndexes:forKey:. Use those private methods to mutate the property from within your own code. I couldn't tell if that's what you meant by: > A second alternative approach is write your own mutable and immutable array > proxies (subclasses of NSArray) instead of using the ones provided by KVC. It > isn't terribly hard. Regards, Ken _______________________________________________ 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]
