Re: Re: ADC Core Data article

FROM : ttempel
DATE : Fri Apr 08 01:50:53 2005

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