Am Di,05.08.2008 um 17:50 schrieb Jeff Johnson:

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.
Yup, that works, because the methods -mutableArrayValueForKey:, - mutableArrayValueForKeyPath:, -mutableSetValueForKey: and - mutableSetValueForKeyPath: manually triggers the notifications.

But:

1. I thought, that it is a "miracle" to him, why only the specified patterns work, but no other.

2.1. If -mutableCollectionValueForKey: should work efficient, you have to return a mutable ivar on your accessors (getter). This means, that *everyone* can change items in that collection without triggering kvo. This is the opposition of encapsulation and very, very dangerous.

2.2. It is possible to give the accessors an immutable type (NSArray, NSSet) and "in reality" return a mutable instacne. IIRC, - mutableCollectionValueForKey: will check the returned class of the instance, not for the type of the arguments. "(I'm nut sure about this, but nearly. You can check it in the debugger by looking on the instance addresses.)

Amin



-Jeff

_______________________________________________

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/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]

Amin Negm-Awad
[EMAIL PROTECTED]




_______________________________________________

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 [EMAIL PROTECTED]

Reply via email to