Re: ADC Core Data article
Re: ADC Core Data article
- Subject: Re: ADC Core Data article
- From: mmalcolm crawford <email@hidden>
- Date: Thu, 7 Apr 2005 14:05:00 -0700
(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
_______________________________________________
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