Re: indexed accessor properties and NSArray/NSMutableArray's
Re: indexed accessor properties and NSArray/NSMutableArray's
- Subject: Re: indexed accessor properties and NSArray/NSMutableArray's
- From: Negm-Awad Amin <email@hidden>
- Date: Tue, 5 Aug 2008 17:37:22 +0200
The basic problem is, that KVO needs Notification-Messages. If you use
KVC-compliant accessor methods this will be done for you by a "faked
class".
If you have a mutable array and change the content (removal, insertion
…), there is no chance of the KVO-runtime system to get a notification
about this. Since you do not use the official methods, nobody does
this work for you. So the work is undone: No snchronization.
You can (and in this case: have to) trigger the notifications
manually. Something like this:
// typed in Mail.app, no warranty for nothing:
NSMutableArray* myRefs = self.myRefs;
[self willChange:NSKeyValueChangeInsertion valuesAtIndex:[NSIndexSet
indexSetWithIndex:0] withKey:@"myRefs"];
[myRefs insertObject:… atIndex:0];
[self didChange:NSKeyValueChangeInsertion valuesAtIndex:[NSIndexSet
indexSetWithIndex:0] withKey:@"myRefs"];
Amin
Am Di,05.08.2008 um 17:22 schrieb Roland King:
I've now read the KVC documentation quite a number of times ..
especially with regards to indexed accessor properties trying to
really understand them. After a bit of messing about in code this is
my understanding ..
1) if your property is an array you don't need to supply the
countOf<key> and objectIn<key>AtIndex: methods for reading the
Array, it will use the Array directly. You can supply them if you
want in which case it will use them.
2) If you don't supply the mutable access methods
insertObject:in<key>AtIndex: and removeObjectFrom<key>AtIndex: but
your property is a NSArray, it will still actually work, what will
happen is the entire array property will be set each time you mutate
it using KVC or bindings to a brand new array, not very efficient.
3) 2) above is true not only for an NSArray, (obviously as it's not
mutable) but for an NSMutableArray too. Even if your property is a
NSMutableArray which could be mutated, if you haven't supplied the
mutable access methods, it won't be, the entire array will be
replaced each time. (this surprised me). If you want the efficient
insert/remove for your NSMutableArray property, you have to write
the accessor methods explicitly.
1) didn't suprise me as the documentation indicates you only need
the accessor methods when the property isn't an array.
2) surprised me a bit as the documentation states that to have
mutable access you *must* implement two extra methods. However if
your entire property is an NSArray or subclass thereof, you don't
have to implement them, it just does it rather slowly.
3) did surprise me a bit given that 2) worked, I expected if it was
smart enough to work around the absence of the mutator methods in
the case of an NSArray, it would realize the property was a
MutableArray, and mutate it directly, but no, it does it the slow way.
I could imagine not bothering to write the mutator methods just
seeing that it worked automagically and never realising that the
entire Array is being swapped out each time I changed it, probably
not very efficient. So the moral of the story for me is .. if I want
any multi-value for a key, even if the underlying instance variable
is an array, write the accessor/mutator methods every time.
_______________________________________________
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
Amin Negm-Awad
email@hidden
_______________________________________________
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