Re: ADC Core Data article

FROM : Marcel Weiher
DATE : Thu Apr 07 16:55:51 2005

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