On May 28, 2009, at 2:16 PM, Quincey Morris wrote:
Well, yeah. The problem is that you're using something with the
behavior of an entity (your custom object) as an attribute. That is,
you want your object graph to include your custom objects (for the
purpose of monitoring their changes), but you haven't implemented
your data model that way. Typically, Core Data *attributes* are
immutable (like NSNumber or NSString) for exactly that reason. The
mutability of your custom object suggests that it should be an
entity, not an attribute. [Sorry, not sure if that's clear. I'm
trying to say the same thing 3 different ways.]
Is there a reason you can't make your custom object a Core Data
entity, and expose its properties (the troublesome instance
variables) as attributes of that entity?
It's not impossible that the willChange/didChange approach can be
made to work, but this sort of thing tends to really crap out in the
face of undo. Consider what happens when you change an instance
variable of a custom object, if the object is already in the undo
history from a previous change. Suddenly, undoing changes ... won't.
Good point!
_______________________________________________
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 arch...@mail-archive.com
