Re: Core Data: first NSKeyValueObservingOptionOld is Null
Re: Core Data: first NSKeyValueObservingOptionOld is Null
- Subject: Re: Core Data: first NSKeyValueObservingOptionOld is Null
- From: Ben Trumbull <email@hidden>
- Date: Tue, 3 Jul 2007 21:48:36 -0700
At 7:23 PM -0700 7/3/07, email@hidden wrote:
CoreData inexplicably publishes nil->value when clearing faults and
value->nil when an object is deleted or invalidated. If you are doing
anything moderately interesting with KVO, you have to tread very, very
carefully.
I logged a bug on on this, but it came back as 'behaves correctly'.
I'm still mystified by this choice and I'm often having to fight this
issue,
so I consider this a design bug. My take on this is that an uncleared
fault is in an indeterminate state. Nil is a valid value for a property
and thus saying that an object has transitioned from nil->value is
tantamount to saying that the object has been edited.
The fault *is* in an indeterminate state; semantically,
philosophically, irreconcilably indeterminate. If a managed object
becomes a fault, we have no idea what the future value of the
property might be. Another thread or process might be changing the
database "as we speak".
A future value might not even exist. It won't if it's never accessed
again or the object is deleted. We cannot provide a real value until
the fault is fired.
At least Schroeder's Cat was either alive or dead, not possibly some
sticky note "what cat?"
The reason for pushing nil values is that KVO *requires* any change
to an observed property to call -willChangeValueForKey: (or
indirectly through auto-KVO, same thing). "requires" in the
"otherwise will seg fault" sense. Calling -willChange... for any
pointer equality change is the definition of KVO compliance.
This doesn't happen when there are no observers because it's not
required. Tree, forest, no listeners, etc.
I agree the behavior is unfortunate, however, it's better than crashing.
File another bug.
--
-Ben
_______________________________________________
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