Am Di,05.08.2008 um 19:11 schrieb Roland King:
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.
not for me it doesn't, see my other reply, without the mutator
methods defined in the class, it doesn't preserve the
NSMutableArray, it changes it for a new array.
Note none of my mail has been about triggering notifications nor
have I been talking about using 'behind the scenes' ways of changing
arrays. My mail has been only about how, when you use a correct KVC
pattern, a binding or mutableArrayValueForKey: and the property
you're mutating happens to actually be an Array, it actually ends up
getting mutated when you do, or do not, provide the mutable accessor
methods.
Okay, I misunderstood your mail.
Sorry for sending the answer directly …
But:
1. I thought, that it is a "miracle" to him, why only the specified
patterns work, but no other.
Not so. The documentation says this
"The key-value coding methods mutableArrayValueForKey: and
mutableArrayValueForKeyPath: provide mutable access to a to-many
relationship, regardless of the class used to model the
relationship. In order to support these methods, your class must
implement two additional methods for each of these keys: -
insertObject:in<Key>AtIndex: and -removeObjectFrom<Key>AtIndex:."
however in the case of an NSArray property, even if you do not
implement them, mutableArrayValueForKey: still provides mutable
access to the contents of the array property, albeit by changing the
entire property for a brand new array. The specified pattern says I
*must* implement those methods for it to work, however it worked
even when I didn't, I went to find out why.
No, I think you misunderstood the documentation. It says, that you
have to implement this methods to get mutable *access*. Mutable access
means in this context, that "mutating accessor mathods" are used. To
change the array or build a new array and than sending a setProperty-
message to the holding instance is not "mutable access", because
semantically *setting* an (old or new) array is no mutation of an
existing array.
Hmm, I know, that I speak englisch very badly. Did you understand,
what I want to say?
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.
That I agree with - and my test in the last mail seems to indicate
that encapsulation is preserved. I wasn't able to get
mutable<anything> to change the array directly. That's good.
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]
