Re: ADC Core Data article
Re: ADC Core Data article
- Subject: Re: ADC Core Data article
- From: Mike Ferris <email@hidden>
- Date: Thu, 7 Apr 2005 07:53:51 -0700
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
_______________________________________________
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