• 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: Tim Lucas <email@hidden>
  • Date: Tue, 4 Jan 2005 10:35:03 +1100

On 04/01/2005, at 8:24 AM, Izidor Jerebic wrote:
The problem arises when the add: method is already implemented and is quite well behaving for purposes of addition (encapsulation), but is not the one Tim suggested. There is no need for the add: method to be like the one above. It might do any sorts of things internally. And it is quite correct to be able to do it, because these things are internal to the object, and can be implemented independently of the environment.

And, besides that, with bindings you need to spend extra effort, because there are more demands on your code - one is the basic model behaviour, and the second is bindings (KVO/KVC).

Jeeez extra effort?! What were Apple thinking when they gave us bindings? We may have to do something ourselves, or *gasp* change some code?


Your decision is: a bit of extra code in the model or a lot of extra code in the controller.

Its a hell of a lot easier testing your model for correctness than testing your bloated controller.

I am not trying to put down the idea of bindings. I am using willChange/didChange internally in all my apps (kind of homegrown KVC/KVO). I just cannot see the benefits of Cocoa implementation being used in general application with complex object model (meaning complex behaviour), compared with the costs...

Yep bindings may not be the best if you have a complex object model (such as an app that puts almost all of the responsibility within the model objects themselves). Bindings best suits applications built using the MVC design pattern, where the complexity usually lies within the controller layer.


Don't forgot that bindings are a great general purpose tool for keeping data between objects in sync and valid -- not just for UI.

- tim lucas

http://www.toolmantim.com


_______________________________________________ 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
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>)

  • Prev by Date: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
  • Next by Date: Re: OT request: Shareware anti-cracking - need info
  • Previous by thread: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
  • Next by thread: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
  • Index(es):
    • Date
    • Thread