• 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: KeyValue Observing rant
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: KeyValue Observing rant


  • Subject: Re: KeyValue Observing rant
  • From: Allan Odgaard <email@hidden>
  • Date: Mon, 26 Apr 2004 18:24:40 +0200

On 26. Apr 2004, at 12:19, Michael Keller wrote:

But one of those "little" drawbacks is, that so basic things like -description won't work anymore.

Not to mention the CF-bridged classes which crash horribly ;)

But I'm ranting because this hidden posing or on-the-fly changing of the isa is not documented and

A bit delayed, but they actually did add this info to the latest iteration of the documentation: http://developer.apple.com/documentation/Cocoa/Conceptual/ KeyValueObserving/Concepts/KVOImplementation.html

it limits other code (like plugins) doing it too.

Well, isa-swizzling only happens if a) a key of the object is being observed and b) the class returns YES for automaticallyNotifiesObserversForKey: -- so if you want to use the technique for code that is aware of it, then it can still be done.

If you want to use it for code unaware of isa-swizzling then it would seem that you're no better than Apple ;)

Although I do agree that it would have been nice if they had introduced a new/better system for dynamically modifying classes.

I do occasionally have situations where I could program "by convention" and save a lot of typing (and maintenance) by generating/wrapping code/methods in e.g. the initialize method of classes (think Aspect Oriented Programming) -- but currently that can only be achieved by using rather cumbersome reflection/introspection, since there is no real API for this, and also a bit of hacking which is generally mutually exclusive with automatic key/value change notifications.

Given also the lack of "delegate" patterns within the NSController subclasses leads me to the conclusion that these classes are far sub-Apple standards because

The complaint I see the most is the lack of delegation when the array controller constructs a new object. This can however easily be intercepted by setting the class name to e.g. "MyNewItem" and then let init of MyNewItem return an NSMutableDictionary with default values.

I would think the goal of bindings is to cut down on the amount of code we need to write, thus having to supply delegates for it is going in the wrong direction. Already bindings do IMHO call for more code than absolutely necessary, although that is probably just me abusing the system for things it was not meant for... ;)






--
et al: used as an abbreviation when referring to a number of people, for
example: "It has been improved by Knuth et al." [syn: and others, et alii]

etc: continuing in the same way [syn: and so forth, and so on, et cetera].
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.


References: 
 >KeyValue Observing rant (From: Michael Keller <email@hidden>)

  • Prev by Date: Re: Quartz from the Command Line
  • Next by Date: Re: KeyValue Observing rant
  • Previous by thread: Re: KeyValue Observing rant
  • Next by thread: Re: KeyValue Observing rant
  • Index(es):
    • Date
    • Thread