• 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: mmalcolm crawford <email@hidden>
  • Date: Mon, 3 Jan 2005 13:40:35 -0800


On Jan 3, 2005, at 1:24 PM, Izidor Jerebic wrote:

- (void) add:(float)addition
{
	float newValue = [self value] + addition;
	[self setValue:newValue forKey:@"value"];
}
Exactly. What I have done in the [second] example is really wrong. But, as you can see, it is easier to get bindings working that way. So if you write bad, un-encapsulated code, it is easier to use bindings. This is the harm I was talking about.
It's not clear what is wrong with Tim's suggestion. If you implement add: as he proposes, then your first example works as required.
The problem arises when the add: method is already implemented and is quite well behaving for purposes of addition (encapsulation)

Then it sounds as if you're violating your own rule by not adhering to the principle of encapsulation within the existing add: method? (I.e. you're changing the instance variable value directly rather than through accessor methods.)


If you want to change the instance variable directly, however, you are free to do so, provided that you add two, very simple, method calls before and after the change is made.


In the example above you have actually created a second layer of abstraction above KVC/KVO - all the behaviour (add:) is implemented via KVC methods. Instead of a single layer (object's methods) now you need two - object's methods (its interface to the external world) and below it KVC/KVO primitives. If this is not more work, I do not know what is.

This should not be more work, if you're adhering to normal Cocoa coding standards and using encapsulation -- you should be calling those accessor methods anyway...


Moreover, you're only looking at one side of the equation. It may well be the case that ensuring KVC, or in particular KVO, compliance requires some additional effort (although typically this will be very simple). However, in most cases this is likely to be outweighed by savings elsewhere (ensuring UI consistency by writing your own glue code can be very complicated, and much more fragile). In some cases it will not. As has been stressed on many occasions, bindings is simply another tool in your coding chest -- it is not necessarily the best tool to use in all circumstances.

mmalc
_______________________________________________
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>)
 >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: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
  • Previous by thread: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
  • Next by thread: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
  • Index(es):
    • Date
    • Thread