On Sep 3, 2009, at 12:14, Alexander Cohen wrote:
Ah, ok, this is more like what i wanted to hear! :) I understand how
@dynamic works, but how to I get to funnel all calls to @dynamic
properties to the same call such as setValue:forKey: or something
like that where i can parse the key and update my internal data and
set the flags i need to set.
No, you're barking up the wrong tree.
There's no "how @dynamic works". @dynamic is a compiler directive
telling it that getter/setter method implementations exist, but just
not in the current compilation unit. There no standard general
mechanism for supplying the implementation.
In the case of Core Data specifically, the built-in implementations
(call them "dynamic" if you want, but that's the same as their being
compiled as "@dynamic") are simply efficient versions of what you
would otherwise have to hand-code. We don't know if they're funneled
through one funnel, several funnels, or a different function for every
property -- that's an implementation detail.
(IAC, Core Data doesn't mark objects as changed in *those* dynamic
methods, but (presumably -- another implementation detail) in the
primitive<Key> dynamic methods.)
I don't how you're ever going to be able to have a class detect
invocations of its subclasses' properties, unless you have the class
muck around in the runtime, replacing methods on the fly.
A better solution, IMO, is to realize that you're considering a design
requirement for your data model, and to design the solution right into
the model. For example, if this is a self-contained class hierarchy
that you're implementing, you could make it a requirement of
subclasses that they invoke something (a superclass method) or inform
something (a controller of some kind) when they modify data values.
Good advice.
Also, instead of worrying about how Core Data does this, you could
just leverage Core Data's change tracking, whether via inheritance or
composition, and respond to the
NSManagedObjectContextObjectsDidChangeNotification. You don't have to
save to one of Core Data's persistence mechanisms just to create a
bunch of managed objects to hold some properties.
- Ben
_______________________________________________
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
