• 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: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???


  • Subject: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
  • From: Izidor Jerebic <email@hidden>
  • Date: Tue, 4 Jan 2005 18:33:46 +0100

I am sorry if I was unclear. Maybe my last email helped a little?

I was looking for an answer to question: "Is it always good to use Cocoa bindings, and if not, what are the criteria (if they exist) which tell you when is it wise and when not so to use Cocoa Bindings?"

The below excerpt is the best I could come up with. If your object model does not fit naturally with KVC/KVO (typically objects with complex behaviour do not fit), it does not make sense forcing it. It might be better to write all view-related code (basically code that would be needed for KVO/KVC) in separate Controller classes, and not in Model classes.

And, as always, it is a balancing act - you need to decide which path to take based on specific circumstances.

It somehow explains (to me, at least) why I was unsuccessful with using bindings in my specific case.


izidor

P.S. This is the email I am referring to:

On Jan 4, 2005, at 10:02 AM, Charlton Wilbur wrote:

It is good to know drawbacks as well as advantages of a tool. It makes for a better choice.

Some of what you claim as drawbacks seem to come from a misunderstanding of the tool - in particular, this insistence that KVC places requirements on the implementation of an object (it doesn't - it just makes it easier to implement if your implementation follows a particular pattern)

Well, let's say the KVC puts some pressure on you and directs you towards certain implementation patterns and away from others. This has nothing to do with how well suited are those patterns for your domain objects, but only has to do with how easy is to implement KVC/KVO.


and that manual KVO is "impossibly complex" (it isn't -- but some implementation patterns make it easier to implement than others).

Again, after the object model is built according to domain requirements, it is substantial work to have it support KVO, if it does not fit already.


So KVC/KVO compliance interferes with your design and implementation, as you start to avoid patterns which are hard to implement with KVC/KVO. This may cause your object models to have worse design/implementation than if you would ignore KVC/KVO.

On the other hand, if you ignore KVC/KVO at the design stage, this may cause substantial work afterwards.

So I do not claim that there are some immovable requirements for KVC/KVO. I am just stating that KVC/KVO interferes with your design choices, and that it may be bad for some situations, notably those that have complex object behaviour (note that those are the ones I consider real OO designs - the rest is just relational scheme of data, no behaviour).


_______________________________________________ Do not post admin requests to the list. They will be ignored. Cocoa-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
  • Follow-Ups:
    • Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
      • From: Charlton Wilbur <email@hidden>
    • Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
      • From: mmalcolm crawford <email@hidden>
References: 
 >Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Izidor Jerebic <email@hidden>)
 >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Tim Lucas <email@hidden>)
 >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Izidor Jerebic <email@hidden>)
 >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: mmalcolm crawford <email@hidden>)
 >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Izidor Jerebic <email@hidden>)
 >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: mmalcolm crawford <email@hidden>)
 >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Izidor Jerebic <email@hidden>)
 >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Charlton Wilbur <email@hidden>)
 >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Izidor Jerebic <email@hidden>)
 >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Izidor Jerebic <email@hidden>)
 >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: mmalcolm crawford <email@hidden>)

  • Prev by Date: Implementing custom views and documents
  • Next by Date: Re: NSArray saveToFile: atomically does not work
  • Previous by thread: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
  • Next by thread: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
  • Index(es):
    • Date
    • Thread