• 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: Mon, 3 Jan 2005 23:01:30 +1100

Izidor,

On 03/01/2005, at 8:16 PM, Izidor Jerebic wrote:
1. Non-debuggable
Once you use bindings, and program does not behave as it should, you can only slaughter chicken or goats and dance and pray to the all-mighty god of Cocoa to help you. There is no tool to help you see what is and is not happening. This is a major drawback

This is annoying I agree, but there is help. Check out GandBug at http://projects.gandreas.com/gandbug/ . Its does runtime debugging of Cocoa bindings.


3. Procedural thinking - objects as structs
This is the major one, and the most problematic. Cocoa Bindings' mental model is of objects as passive lumps of data. It shows its inheritance from EOAssociation and the way it is most correctly used, but nevertheless, it is quite dangerous, because it forces a developer to create the application object model in a very non-OO way, if it is to work nicely with bindings. Bindings are really well suited to extremely simple objects - a C structs with set/get methods (which actually are not objects in proper OO sense - those contain behaviour and data). Anything else makes the developer write additional code to make objects look like this.

You've lost me with the C structs comment. How is it less OO? All participants in binding are either messages, objects or object proxies.


And if a developer is just starting with Cocoa, this non-OO way of thinking will subconsciously make his object modelling very wrong, indeed. As an example, lets assume we have a calculator object, which can perform operations (lets say that calculator holds the operations as stack, so you can get a paper trail, so nothing as 'value' variable exists inside of object). There are two ways to implement adding.

First:
  [calculator add:someNumber] ;

Second:
  val = [calculator value] ;
  newVal = val + someNumber ;
  [calculator setValue:newVal] ;

What you've done has completely lost the encapsulation of the 'add' method to the calculator object.


You can still use [calculator add:someNumber], but inside the 'add' method you would do:

- (void) add:(float)addition
{
	float newValue = [self value] + addition;
	[self setValue:newValue forKey:@"value"];
}

IMHO, the first approach is the correct one. But if you want to use bindings, you will need to write additional code for set/get. The second one (procedural, not object-oriented) will get you bindings working for free. No new code. So if you subconsciously learn this, your code will steadily become procedural and not object-oriented.

In conclusion, I think that bindings are great for preferences (I did manage to implement them with bindings) and data-oriented parts of applications (inspectors, data-entry). Bindings will probably become extremely useful with CoreData, as its predecessors were.

But they are not suitable for general development, and can be really harmful to proper object-oriented modelling, if applied indiscriminately...=

Anything applied indiscriminately to anything can be harmful. How about outlining the situations you think it would be harmful to apply Cocoa bindings?


I would like to be corrected and I really welcome any response that would do something to point out the mistakes I made in my thinking. Especially any positive experiences and examples. I do not want to miss any benefits.

I can testify the research staff, teaching staff and students of my uni (UNSW) have found bindings to be extremely effective and have never had to sacrifice object modelling to ensure KVC compliance (except for maybe adding some extra code). Personally I have found Cocoa bindings to encourage better object designs (for example using a Window Controller for each window and binding through File's Owner).


- tim lucas

_______________________________________________
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: Izidor Jerebic <email@hidden>
References: 
 >Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Izidor Jerebic <email@hidden>)

  • Prev by Date: RE: Re: How to use NSLock
  • Next by Date: Mounting network disks
  • Previous by thread: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
  • Next by thread: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
  • Index(es):
    • Date
    • Thread