Re: ~"Smalltalk is so confusing it's as bad as HYPERTEXT!~"

[Bob Perez <bobp>]

That quote reminds me of an observation I've made while learning to program
objects. When I program using standard procedural C, I spend a fair amount of
time on little performance hacks, shaving every little bit of execution time
off of my functions, and generally exalting efficiency over structure (but
not to too much of an extreme).

Now, however, fresh from "Structure and Interpretation", I find myself in
the midst of a classification frenzy, freely classing and subclassing away
all of my old parameters in exchange for a robust set of messages that
respect good modularity boundaries.

I don't think as much about little performance hacks anymore, although I
grow increasingly suspicious that all of the message passing overhead is
going to eat me alive someday. I now understand why MacApp suffered so long
with the reputation of a performance hog. It's *not* just that it was a
sluggish system (although I suspect it probably was, to some extent); the
real problem was that OOP makes it EASY to be sloppy. I suppose a lot of the
early MacApp users weren't disciplined object programmers (even though I bet
a lot of them were efficiency junkies in their prior lives). And the result
was a lot of slow, sloppy programs.

The smalltalk quote reminds me of a question I've been wanting to ask OOP
gurus for some time: is there additional overhead associated with each new 
level of object in the overall hiearchy? For example, in all of the books
I've read concerning OOP on the Mac, Rects are used as examples of simple
objects that encapsulate small amounts of data (4 coordinates) with a small
suite of behaviors (Draw(), Erase(), etc.). This suggests that one could 
build up a rather complex library of interface objects built on a lot of
these smaller objects. The TextDocWindow object is a subclass of DocWindow,
which is a subclass of Window, whose EraseWindow() routine is just a call to
the portRect's Rect object's Erase() method, and so on.

In straight procedural C, I would have just opened a window, stuffed my text
into it and erased it with a call to EraseRect(&myWindow->portRect). 

How much overhead gets introduced in all of this classing and subclassing?
Are there significant differences in the approaches taken by C++ and, say,
Object C?

-- bobp