• 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: Design Question: Pro & Cons of KVC/KVO
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Design Question: Pro & Cons of KVC/KVO


  • Subject: Re: Design Question: Pro & Cons of KVC/KVO
  • From: Ken Thomases <email@hidden>
  • Date: Thu, 21 Aug 2008 19:52:24 -0500

On Aug 21, 2008, at 7:09 PM, Erik Buck wrote:

On Aug 21, 2008, at 7:12 PM, Ken Thomases wrote:

On Aug 21, 2008, at 12:54 PM, Erik Buck wrote:

KVC also provides support (hooks) for change management so that any change to a property can have application defined side effects like registering an undo event or validating the change.

Hooks other than the accessors it might invoke? I'm not aware of that.
In order to make your classes KVC compliant, you must either write the appropriate accessors or override the valueForKey: and related methods. The "hooks" in fact are the accessor methods or the valueForKey: type methods.

Well, OK. In that sense, every method is a hook, insofar as a subclass could override it to do something before/after/instead of what the method would normally do.


When I think of "hooks", I usually think of methods that exist solely to provide clients an opportunity to do something at certain points. The framework calls them not for its own purposes but just to give clients an opportunity to do something else. For example, the real meat of -[NSWindowController window] is in its -loadWindow method. However, for the convenience of its clients (and solely for that reason), it also invokes -windowWillLoad and -windowDidLoad (and the associated document's -windowControllerWillLoadNib: and - windowControllerDidLoadNib:, if present).

And, of course, delegate methods are a prime example of hooks.

I suppose that's a pedantic distinction, though.


Again, I don't think KVO takes advantage of existing hooks. It adds those hooks by generating subclasses dynamically and isa- swizzling. Unless and until you add a KVO observer to an object, it doesn't have any hooks.

The hooks are just the accessor methods or KVC compliance methods. They exist for every KVC compliant class.

Technically, a class may be KVC-compliant even without the KVC accessors. If the class has the appropriately-named instance variable, it qualifies (although I'm sure we agree that programmers _should_ provide the accessors, especially for proper memory management).


I guess, in that case, you might consider the -valueForKey: and - setValue:forKey: methods themselves to be the hooks. *shrug*

Cheers,
Ken
_______________________________________________

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: 
 >Re: Design Question: Pro & Cons of KVC/KVO (From: Erik Buck <email@hidden>)
 >Re: Design Question: Pro & Cons of KVC/KVO (From: Ken Thomases <email@hidden>)
 >Re: Design Question: Pro & Cons of KVC/KVO (From: Erik Buck <email@hidden>)

  • Prev by Date: reusing cookies set in UIWebView
  • Next by Date: Preventing windows from being dragged
  • Previous by thread: Re: Design Question: Pro & Cons of KVC/KVO
  • Next by thread: Design Question: Pro & Cons of KVC/KVO
  • Index(es):
    • Date
    • Thread