Re: ADC Core Data article
Re: ADC Core Data article
- Subject: Re: ADC Core Data article
- From: Ondra Cada <email@hidden>
- Date: Wed, 6 Apr 2005 12:21:00 +0200
Paul,
do you know EOF? You may want to check its documentation until the
CoreData one is available... I kind of fear you don't have a proper
idea of the complexity of such a thing. My comment of NSArchiver was
not meant to be precise, but just to put the things into a proper
perspective :)) CoreData is definitely *not* just some kind of
archiving/unarchiving on steroids, it is *much much* more.
On 6.4.2005, at 8:22, Paul Szego wrote:
Many other frameworks face the same problem - and there's usually two
approaches. The first, and most restrictive, is to force you to extend
a specific base class with a bunch of behaviour built in. Another is
to define the responsibilities of a class that wants to "play ball"
(e.g. in Java via an interface, in ObjC via a protocol) and let it
decide how to best achieve those.
If you do insist... given the ObjC dynamic behaviour, it actually is a
reasonably safe presumption you still, in principle, *can* do this
(=create a non-managed object class which would be able to participate
in the Core Data persistent object graph). Perhaps you would have to
hack-out some undocumented APIs, but it would be pretty strange if
impossible.
The latter approach doesn't preclude providing a base or mixin class.
The former approach is often too restrictive to be useful, especially
when you want to make use of the framework for existing code.
That said, there seems to be -- at the very least in some 99.99% of
situations -- absolutely no sensible reason to do anything remotely
like that.
The managed object behaviour (well, the EOF enterprise object behaviour
for sure, and it seems CoreData in this regard would not differ
terribly from EOF) is *very considerably* specific and different from
other ones. I fear you could argue just the same way that, say,
NSString should not be a class apart, but that there should be an
explicit protocol which would allow any NSObject to behave as one :)
Even if you currently have a E/R-based network of data objects in some
app, you would have to make *considerable* changes to switch to
CoreData for them: you'd have to define entities, and provide for each
data object to know which one it belongs to; you'd have to change the
application logic to use (and properly at that!) the managed context
instead of whatever services you use currently; you'd have to change
the data storage methods considerably to be fully KVC/KVO compliant,
and who knows what else. To change the base class would be a completely
negligible task in all that.
---
Ondra Čada
OCSoftware: email@hidden http://www.ocs.cz
private email@hidden http://www.ocs.cz/oc
_______________________________________________
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