On Thu, 17 Jun 2010 14:51:04 -0700, Jerry Krinock <je...@ieee.org> said:
>
>On 2010 Jun 17, at 12:21, Matt Neuburg wrote:
>
>> My question is, does anyone have a *simple* approach to this common problem?
>
>Not necessarily any simpler, but another technique which may be better than
observing each object in some situations, (although not yours, without
modification). Implement custom setters for properties you want to observe, and
in them check for value changes and post notifications. Improve efficiency by
coalescing. Watch for infinite loops; posting styles can be helpful.
>
>Not a good idea with NSMutableDictionary, though
Yes, I was afraid that might be the way: Don't use NSMutableDictionary,
implement your own model object so you have some more control.
It's a pity that key paths break down when they hit an array.
@"theArray.name" accesses all "name" properties of whatever's in the array,
but @"theArray[0].name" is not a valid path, if you see what I mean... :)
On Thu, 17 Jun 2010 17:33:46 -0500, Ken Thomases <k...@codeweavers.com> said:
>I'm not sure to which example of mmalc's you're referring, but you should
implement the mutating indexed accessors for your to-many relationship
properties, and always go through those. So, for example (typed in mail):
>
>-(void)insertObject:(id) object inWidgetsAtIndex:(NSUInteger)index
>{
> [_widgets insertObject:object atIndex:index];
> [object addObserver:self forKeyPath:@"name" options:0
context:myUniqueContext];
>}
That's pretending that "self", who owns the array, is also the one who wants
to do the observing, that it always wants to do it, etc. Obviously that's
easy.
I'm talking about the general problem of any object registering through the
array's vendor to get notified about changes in the array's items'
properties. The mmalc solution (in GraphicsBinding) is clear enough -
register for changes in the array, and register for changes in the
properties of every item in the array individually, and then register on
added items or unregister on removed items whenever you hear that the array
has altered - but a beginner might find it heavy going. m.
--
matt neuburg, phd = m...@tidbits.com, <http://www.tidbits.com/matt/>
A fool + a tool + an autorelease pool = cool!
AppleScript: the Definitive Guide - Second Edition!
http://www.tidbits.com/matt/default.html#applescriptthings
_______________________________________________
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
