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: Roland King <email@hidden>
- Date: Wed, 06 Aug 2008 00:00:14 +0800
On Aug 5, 2008, at 11:50 PM, Jeff Johnson wrote:
On Aug 5, 2008, at 10:22 AM, Roland King wrote:
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.
Roland,
How are you mutating your array? If you do [[myObject
mutableArrayValueForKey:@"myArray"] addObject:anObject], it should
preserve the current NSMutableArray even without indexed accessors.
This seems to work in my testing, at least.
-Jeff
An ArrayController is doing it for me. I started with the property
being an NSArray(), to see what happened, and the entire NSArray() was
switched on each addition, I know this because I implemented set<key>
and stuck a breakpoint in it. That made sense. Then I changed it all
to NSMutableArray, the instance variable, the property accessor
methods, everything but still it called the set<key> mehtod and
replaced the entire Array and didn't mutate the one in the property.
Only after I put in the indexed accessors did it start using them.
The method you mention is what I was just about to try out in a
standalone piece of code to check it, it'll be interesting if that
does mutate the array directly, I did expect however that
NSMutableArray, being as it's 'the' array controller, would be calling
the correct KVC-compliant methods. Perhaps it's working differently as
the ArrayController is bound to the property.
_______________________________________________
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