• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: watch changes to any properties on an object
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: watch changes to any properties on an object


  • Subject: Re: watch changes to any properties on an object
  • From: Alexander Cohen <email@hidden>
  • Date: Thu, 3 Sep 2009 16:11:16 -0400


On Sep 3, 2009, at 3:44 PM, Quincey Morris wrote:

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.

I'm with you. I've realized that's the way to go. Concerning CoreData, i was looking for info or ideas on the implementation details. thx for the info.


AC
_______________________________________________

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


References: 
 >watch changes to any properties on an object (From: Alexander Cohen <email@hidden>)
 >Re: watch changes to any properties on an object (From: Jens Alfke <email@hidden>)
 >Re: watch changes to any properties on an object (From: Alexander Cohen <email@hidden>)
 >Re: watch changes to any properties on an object (From: Jens Alfke <email@hidden>)
 >Re: watch changes to any properties on an object (From: Alexander Cohen <email@hidden>)
 >Re: watch changes to any properties on an object (From: Quincey Morris <email@hidden>)

  • Prev by Date: NSControlTextDidChangeNotification - What key pressed?
  • Next by Date: Re: NSDictionary, allKeys and the NSAutoreleasePool
  • Previous by thread: Re: watch changes to any properties on an object
  • Next by thread: Re: watch changes to any properties on an object
  • Index(es):
    • Date
    • Thread