Re: Re: ADC Core Data article
Re: Re: ADC Core Data article
- Subject: Re: Re: ADC Core Data article
- From: email@hidden
- Date: Thu, 7 Apr 2005 19:50:53 -0400
On Apr 7, 2005, at 5:07 PM, Timothy Reaves wrote:
but I'd still like my objects to be objects.
They are objects.
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.
Well, this is a question of semantics (as is much of this thread
already). It's still an object, albeit you might consider it a
degenerate object that has no explicit methods or overrides that you
developed, but make no mistake it is still an object, and responds to
everything that it's parent object(s) support.
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.
Not necessarily at all. There's nothing that expressly states that your
KVC accessors and mutators can't go ahead and do certain things. If
they're there then they're called, and the data members aren't directly
poked and prodded behind your back. KVC, et al, has never demanded that
you abandon object oriented techniques and simply treat everything as
key/value pairs. It's really more of an "addressing" convention, as
with the JavaBean idea. The blog "{return self}"
(http://returnself.com/blog/) has an interesting discussion along these
lines (available here:
http://returnself.com/blog/2005/03/09/beyond-bindings-cool-stuff-about-
key-value-coding/) , as does Scott Stevenson over at Theobroma Cacao
(http://theocacao.com/document.page/6). Hell, I even did something
similar at work using Java, sometimes even with InvocationHandlers (but
not absolutely necessary) when dealing with "free form objects" that
persist in/out of a set of mysql tables, and it worked quite well.
Besides, there's nothing/no-one demanding and/or stating that you
_must_ use CoreData. I'm guessing---purely guessing---that there may be
some policy/constraint features available in the entity relation
mapping that you can doodle-up in XCode 2, and if not perhaps in the
very near future.
--george (ty) tempel
--ty
_______________________________________________
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