When you add an observer to an object first time, its class is
implicitly changed to a KVO_originalClassName (subclass of original
class). This subclass adds willChange…/didChange… methods for
observable properties.
If you send willChange… before you add an observer, it does nothing.
But if you send didChange… just after, the app will crash, because
new KVO_originalClassName nerver receives willChange…
The idea is to maintain counter of all received willChange… messages
(per key) and decrease it in didChange…
When KVO_originalClassName is created and didChange… is received
(without opening willChange… to new class), exception is not thrown
immediately, but the counter is checked first.
If it's greater than 0, then didChange… just closes
an unboserved willChange… Otherwise exception is thrown, as expected.
When you change the top level object, observer MUST receive value
for the key path of the previous top level object as old and
value for the key path of the new top level object as new.
- Moved common CPArray/CPSet collection KVC operators to _CPCollectionKVCOperators.
- Implemented KVC operator dispatch using Objective-J.
- Fixed infinite loop with empty collection in @min, @max and @sum operators.
- Correctly return valueForUndefinedKey when necessary.
- valueForUndefinedKey reason uses raw description for consistency, class' overridden description may not helpful at all.
- Don't create a forwarder for @ operators with property paths.
- Fixed CPSet -valueForKeyPath to correctly deal with nil/undefined/empty values.
- Added tests for collection KVC operators.
- enumerator -nextObject should always compare against nil for clarity, correctness, and consistency.
- valueForKeyPath: looped over individual components, which meant classes couldn't override valueForKeyPath: to do multi-part keys (needed for operators)
- CPArray's valueForKeyPath: implementation was incorrectly parsing the operator if it was a simple key