Re: ADC Core Data article

FROM : mmalcolm crawford
DATE : Thu Apr 07 23:05:00 2005

(This is a general comment, not intended just for Timothy.)  Voicing 
concerns based on conjecture and misunderstanding is not helpful. 
Please wait until Tiger is released before making issues of something 
that may not be an issue at all.


On Apr 7, 2005, at 1:03 PM, Timothy Reaves wrote:

> If my Foo domain object is simply a map interface that knows how to 
> look
> up a strings key and return the associated value, then you are 
> incorrect,
> it is not an object.  It is a data type.
> An object has data, and methods that operate on that data.
>

A managed object has data and methods that operate on that data.

The article states, "The NSManagedObject class implements the 
functionality needed to fully integrate into the Core Data framework 
and can represent any entity. It acts as a dictionary in that any of 
its attributes and relationships can be set using Key-Value Coding 
(KVC) as well as observed using Key-Value Observing (KVO)."

Assuming NSManagedObject to be an analogue of EOGenericRecord in 
EOF...  if in EOF you don't want or need to add custom behaviour (or 
for example you're at an early stage in your development and want to 
maintain agility prior to locking down class names etc.) then there 
is no need to subclass EOGenericRecord.  It provides all the 
behaviour you require to represent an instance of any entity you 
define in your model.  At the stage at which you want to add custom 
behaviour, you create a subclass and implement whatever methods you 
deem appropriate (whether they be custom accessors, validation 
methods, or other complex business logic).  If you decide you never 
want to represent an entity using EOGenericRecord, you are perfectly 
free to create custom classes for all your entities.


> Now, as others have pointed out, at a minimum we will be able to 
> subclass
> and add back our object semantics.  But - as many others - have 
> very well
> pointed out, if I have to implement my accessors & mutators as KVC
> compliant methods, we loose a good deal.
>

It is not clear to me what would be "lost" by requiring that accessor 
methods follow well-established patterns that are used pervasively 
within Cocoa?

mmalc