• 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: Tue, 4 Jan 2005 08:01:29 -0800


On Jan 3, 2005, at 11:14 PM, Izidor Jerebic wrote:
On Jan 3, 2005, at 10:40 PM, mmalcolm crawford wrote:

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.
What if there is no 'value' instance variable ?
Why do you all insist that implementation must have instance variable called 'value'? Like there is no other way?


Umm, on many occasions in the past (moreso in WebObjects courses than here, but...) I have stressed the "equivalence" as far as KVC goes between instance variables and methods -- KVC doesn't care if there is a real instance variable or not, provided there's a method. So in abstract I'm certainly not insisting there is a variable. The reason for focussing on variables is that, since it seemed that you weren't calling accessor methods, it seemed reasonable to assume that there was a variable (mea culpa if this was not the case)...


Lets say that one of the instance variables of the calculator is the array of objects, denoting operations, and when the value is requested, it is always calculated on demand from this array.
This is perfectly OK implementation, hiding the complexities from external world. Why did we choose this implementation? Well, maybe it is suitable for other operations that we want the calculator the perform, like getting the trace (for printed trail), whatever...
This example and various arguments clearly shows the problems - everybody immediately assumed that there must be an instance variable 'value'. This is implementation detail and nobody can assume what the implementation is, based on the object interface.
And of course I do not use getters/setters with this implementation. Why would I? Internal implementation objects are not (should not be) available to the external world, so there should be no getters/setters for these instance variables.


It's not clear why you would not at least have the equivalent of a "getter", even though it returns a derived value. This is a standard Cocoa design pattern.

But then you say, "so there should be no getters/setters for these instance variables," so it's not now clear to me whether there are instance variables or not. Really, it doesn't matter. The simple fact is that, to reiterate, Cocoa has existing patterns for accessing values.

If, as *seems* to be the case, the derived value is dependent on another value, so a notification should be sent if the other value changes, then you can probably arrange for this to happen automatically using setKeys:triggerChangeNotificationsForDependentKey:.


If I want to make this object KVC/KVO compliant, there is substantial work to be done. And not because the object is badly designed. I can change its implementation any time. This means its design is OK. KVC/KVO is influencing its implementation, not design.

I suspect that for most applications the effort involved in ensuring KVC/KVO compliance is minimal, and typically involves adhering to patterns that have been encouraged for some time. Perhaps you could give a concrete example to show why this is not the case here, as I'm afraid it's still not completely clear to me? And again, typically it should be the case that any effort expended in ensuring KVC/KVO compliance is significantly outweighed by the effort that would be expended writing the glue code.

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


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

  • Prev by Date: Re: [Q]How can I bring the information of the file that I select from desktop to a program that I intend to make?
  • Next by Date: Re: Where is the API for proxy icons?
  • Previous by thread: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
  • Next by thread: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
  • Index(es):
    • Date
    • Thread