Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
- Subject: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
- From: Izidor Jerebic <email@hidden>
- Date: Tue, 4 Jan 2005 11:28:43 +0100
On Jan 4, 2005, at 10:02 AM, Charlton Wilbur wrote:
It is good to know drawbacks as well as advantages of a tool. It
makes for a better choice.
Some of what you claim as drawbacks seem to come from a
misunderstanding of the tool - in particular, this insistence that KVC
places requirements on the implementation of an object (it doesn't -
it just makes it easier to implement if your implementation follows a
particular pattern)
Well, let's say the KVC puts some pressure on you and directs you
towards certain implementation patterns and away from others. This has
nothing to do with how well suited are those patterns for your domain
objects, but only has to do with how easy is to implement KVC/KVO.
and that manual KVO is "impossibly complex" (it isn't -- but some
implementation patterns make it easier to implement than others).
Again, after the object model is built according to domain
requirements, it is substantial work to have it support KVO, if it does
not fit already.
So KVC/KVO compliance interferes with your design and implementation,
as you start to avoid patterns which are hard to implement with
KVC/KVO. This may cause your object models to have worse
design/implementation than if you would ignore KVC/KVO.
On the other hand, if you ignore KVC/KVO at the design stage, this may
cause substantial work afterwards.
So I do not claim that there are some immovable requirements for
KVC/KVO. I am just stating that KVC/KVO interferes with your design
choices, and that it may be bad for some situations, notably those that
have complex object behaviour (note that those are the ones I consider
real OO designs - the rest is just relational scheme of data, no
behaviour).
izidor
_______________________________________________
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: Charlton Wilbur <email@hidden>) |