• 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:13:57 -0800


On Jan 4, 2005, at 1:07 AM, Izidor Jerebic wrote:
On Jan 4, 2005, at 9:29 AM, Izidor Jerebic wrote:
On Jan 4, 2005, at 8:37 AM, Charlton Wilbur wrote:
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.

KVC says, roughly, that if you try to read a key called "foo" that it looks (in some order) for an instance variable called foo or _foo or a method called foo. In your example, you might have a reason not to store the value -- that's fine. You can make it KVC compliant by providing a method that takes no arguments, with its name the same as they key you are using. If you only want to be able to read one value from it, that's one method that you need to implement -- hardly "substantial work."
One additional important point that I forgot in my previous email: this is the Model we are changing, and the reason for changes is the View. So we are putting the view-related stuff into the model. This bothers me a lot.

It's not clear to me why you should be adding view-related methods to a model? Certainly there should be no need to do so to use KVC/KVO.

EOF did not have these problems, because in EOF there was a way of having all your logic in a category (separate file), using the accessors. But with EOF the design usually started with the relational scheme, and object classes were generated from it. Just the reverse of OO design, where you specify goals, and then proceed from goals (external interface) to internal implementation.

Bindings certainly allows you to put your logic in a separate category. It's not clear why this is relevant?

As for EOF in general, in contrast to your assertion, because of the way KVC works, you remained abstracted from the underlying implementation. If you chose to use an EOGenericRecord to represent your entity -- with no instance variables -- you could do so just as well as if you decided to create a custom class that still used the generic record's internal data storage, just as well as you could if you decided to use explicit instance variables, whether represented by object or scalar values. The flexibility of EOGenericRecord (obviously coupled with your EOModel) made it very easy to start creating your application structure without having to write any code or specify any internal implementation for your data-bearing objects.

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

  • Prev by Date: Re: Where is the API for proxy icons?
  • 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