Re: ADC Core Data article

FROM : Mike Ferris
DATE : Thu Apr 07 16:53:51 2005

>> Sure does!
>>
>>    result = [employee valueForKey:@"name"];
>> vs.
>>    result = [employee name];
>>
>> The second is:
>>
>> 1.    Expressed directly in the target language (Occam's Razor,
>> anyone?)
>> 2.    More compact
>> 3.    Easier to read
>> 4.    About an order of magnitude faster ( about 8 times, to be a bit
>> more precise )
>>
>> An order of magnitude here, an order of magnitude there, and soon
>> enough you're talking about real performance pigs...

>
> If you wrote everything in C instead of Objective-C, you'd lose all
> the overhead of method dispatch.  How much longer does it take to
> dispatch a method call instead of just calling a function?  If you
> wrote the whole thing in one long continuous stream of PowerPC
> assembly, it would be still faster, because you could hand-optimize
> the assembly and get it to run REALLY quickly!  Of course, this is not
> a sign that either is better -- programmers get significant benefits
> from using C instead of assembly, and from using Objective-C instead
> of C, and from using bindings instead of straight method calls.
>
> In the case of bindings (as well as in the two examples I gave),
> bindings are not a pure *replacement* for method calls, they're an
> *alternative* to it that makes some things a lot easier at the cost of
> performance.  They're not meant to be a replacement for routine
> accessor functions (though you can certainly use them for that!) but
> as a way of doing a particular sort of introspection that happens to
> be very useful for writing generic UI classes.  The cases you'd use
> bindings in are *not* the cases where a simple accessor would be
> appropriate; they're the cases where using bindings instead of simple
> accessors allows one to eliminate 10 lines of code here, 10 lines of
> code there.
>
> All you've really managed to demonstrate is that bindings do not make
> a good replacement for simple accessor calls.  We knew that already.
>
>

I think what Marcel is saying is not that generic KVC and bindings and
core data are bad.  Just that generic accessors are appropriate to use
for generic things and specific ones are nicer to use for specific
things.  That's why there should be both.  I don't see much room for
argument that his second line of code above is more to-the-point.

And that's just what KVC is meant to give you.  If you have foo/setFoo:
methods, KVC will work by calling them.

Now NSManagedObject gives you a way to have KVC without the specific
accessors, which is great for getting started quickly, and if wiring up
simply binding-based interfaces is all you'll use the objects for it is
probably sufficient.  But if you will have a significant amount of code
written that talks directly to your model objects, it is nice to give
them a more convenient, specific, and typed API to use.

Mike Ferris