Add KVO tests and remove hack in -[COObject replaceContentOfCollection:...

[ericwa]

I tried removing this hack:

        // FIXME: Remove this copy hack to ensure KVO doesn't report a old value
        // identical to the new one.

        // NOTE: This mess is because -copy on a COPrimitiveCollection preserves
        // the number of -beginMutation calls, and we want the copy
        // to go back to being immutable once we are finished modifying it.
        if ([self isCoreObjectCollection: collection])
        {
            collection = [collection copy];
        }
        else
        {
            collection = [collection mutableCopy];
        }
        [(NSMutableArray *)collection setArray: content];

https://github.com/etoile/CoreObject/blob/master/Core/COObject.m#L977

but it caused weird failures in the attributed string tests.
I don't understand the comment:

        // FIXME: Remove this copy hack to ensure KVO doesn't report a old value
        // identical to the new one.

Anyway, we should add KVO tests to find out exactly what that hack is doing, and then remove the hack.

[qmathe]

I'm not 100% of every details in the explanation below, but iirc it's something close to that.

When you call -willChangeValueForKey:, KVO invokes -valueForKey: and retains/copies the returned value that will be made later available in the change notification under the key NSKeyValueChangeOldKey.

I can think of two explanations for this hack, either COPrimitiveCollection classes were not implementing NSCopying at the time this comment was added, so KVO couldn't make a copy to snapshot the collection prior to the change, or simply KVO never copies the collection but retains it on -willChangeValueForKey:.

If the collection is not copied, after mutating it, we cannot assign the collection in -replaceContentOfCollection:withCollection: like that:

collection = content

but we must do

collection = [content copy]

If we don't that and 'collection' is identical to 'content', then the returned collection to be put in the variable storage is the same than previously, this means both NSKeyValueChangeOldKey and NSKeyValueChangeNewKey will return the same value when they shouldn't.

From what I remember it's a hack I added to get some tests passing (may be the attributed string tests in fact).