Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
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
| 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>) |