Re: C++ not OOP? (Was: Language Efficiency

[Erik Naggum <erik@naggum.no>]

[Fernando Mato Mira]

|   In article <3n8jdv$jer@watnews1.watson.ibm.com>, ncohen@watson.ibm.com (Norman H. Cohen) writes:
|   
|   > It should be noted that even in languages without direct linguistic
|   > support for multiple dispatch, the same effect can be achieved in a
|   > straightforward way by redispatching.
|   
|   Of course. And you can achieve the same effect as single-dispatch by
|   using function pointers in a C program..

unless I have missed something crucial, I think both of you may have missed
something crucial.

your idea seems to be to have Grand Unifying Classes from which devices and
shapes inherit Grand Unifying Methods, such that all shapes are implemented
using a set of abstract methods that all devices implement.  I object to
the very idea of Grand Unifying Classes, on the grounds that abstraction
that achieves a Unifying Abstraction over devices (in particular) will have
great cost in both the abstraction process and the implementation, more
notably the abstraction process.  whereas it is nearly trivial to design
and implement drawing a shape on a device using device-specific code, it is
exceedingly hard to design the Abstract Device that will capture sufficient
power of real devices, not to mention ways to optimize the Grand Unifying
Methods for a particular device.

one of the reasons that I found "object-oriented" programming in C++ to be
exceedingly hard was the requirement to make counter-intuitive and overly
abstract abstractions only to conform to the lack of ability to dispatch to
the proper classes.  I have only experimented with CLOS and Dylan, but what
I found was indeed that I could write better code to do specific tasks, and
that I could intuit the abstract classes, if and when appropriate _after_ I
had the necessary experience to talk about them, and _after_ I had a chance
to decide whether they were indeed appropriate.  for me, programming is a
learning process, and I found that C++ was actively hindering that process,
whereas both CLOS and Dylan encourage me to make abstractions when I have a
greater understanding, an understanding that could not exist prior to
design and implementation of individual subclasses of some Unknown Grand
Unifying Class.

maybe I'm doing something wrong, but premature abstraction seems as bad as
or worse than premature optimization, both of which are encouraged by C++
and discouraged by both CLOS and Dylan.

(I'd appreciate if someone more experienced in either language would let me
know if I'm wandering off in the wrong direction.)

#<Erik>
--
sufficiently advanced political correctness is indistinguishable from irony