Re: ADC Core Data article
Re: ADC Core Data article
- Subject: Re: ADC Core Data article
- From: Marcel Weiher <email@hidden>
- Date: Thu, 7 Apr 2005 15:55:51 +0100
On 7 Apr 2005, at 14:11, Charlton Wilbur wrote:
On Apr 7, 2005, at 5:59 AM, Marcel Weiher wrote:
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.
Not really. In fact, if I wrote this in C, it would look like this:
objc_msgSend( employee, sel_getUid( "name" ) );
It would be just as fast/slow as using Objective-C message send
syntax (a bit slower, because the selector has to be looked up).
Do you see the similarity with "valueForKey:"? In both cases, what
you actually want to do (send the message "name") is not expressed
using the original programming language, but as a string argument.
One of the issues with this approach is that your programming
language doesn't get to check what you wrote at all, and significant
amounts of computation have to be shifted to runtime, even for bits
where everything is known at compile time.
Taking that approach (of embedding strings that carry your semantics)
to extremes, you end up with: [employee
interpret:programInNewProgrammingLanguage]. In fact, KVC *is* a
language, although a very impoverished one.
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!
Hmm...you did notice that performance was only 1 of the 4 points I
mentioned? My main point is about expressing intent clearly.
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.
While I agree that KVC and bindings can provide benefits, I am not
convinced that embedding a string-based mini-language is the best way
to obtain those benefits. It certainly has significant drawbacks.
In the case of bindings (as well as in the two examples I gave),
bindings are not a pure *replacement* for method calls,
Could you please use "message send"? Thanks!
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!)
Who said "name" was an accessor? Or a function? It is a message,
and objects provide their services via the messages they respond to.
They are not datastores that provide keyed access to the data
contained therein. One of the problems with KVC is that it
encourages the latter view, with dumb data-bearing objects
manipulated by external controllers etc. Good bye object-oriented
programming!
but as a way of doing a particular sort of introspection that
happens to be very useful for writing generic UI classes.
Well, why not use message-based introspection instead?
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.
My response was to "it doesn't get much easier than [valueForKey:/
setValueForKey:]". I said it does, not that there is *never* a use
for valueForKey:/setValueForKey:. Calm down.
Anyway, while I am one of the biggest fans of convenience (and saving
code) there is, it isn't always a good idea if what we intend to do
becomes obscured. See Richard Gabriel's comments on programming as
compression, and the dangers of compression.
Cheers,
Marcel
_______________________________________________
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