Re: C or C++?
On May 15, 6:00 am, Phlip <phlip2...@gmail.com> wrote:
Gianni Mariani wrote:
I don't think it supports the previous posters argument that OOP
requires polymorphism. I'm no OOP crtitic so I don't know if there is
anything wrong with it if it smacked me in the head.
This question is a book unto itself. OO _should_ be defined so its
root principle is polymorphism, but the term OO is too abused for
WikiPedia to arbitrate any consensus.
One Robert C Martin says it best (IIRC): "Structured programming is
discipline imposed upon direct transfer of control flow. OO
programming is discipline imposed upon indirect transfer of control
flow."
By "discipline" he means that the statement if(foo){ int bar = 42; }
will refuse to compile that 'bar' outside its block {}. That is
Structured Programming - matching the scopes of variables to branches
of control flow.
In a structural paradigm, you can call methods indirectly, achieving
polymorphism, in one of two ways. You can write a 'switch' statement
that reads a type code, and branches to each target type, or you can
use a function pointer. Both systems suck, because to add another type
you must add a case to every matching switch statement, and to use a
function pointer you must generally assign the pointer, possibly
typecast it to call it, possibly check it for NULL, etc. All this
cruft raises the cost of polymorphism.
An OO language fixes this by merging the switch and function pointer
into a secret jump table. The language will typesafely manage the jump
table for you, mostly at compile time. That allows programmers to
impose discipline on how they partition a program into polymorphic
code blocks. And, once again, the compiler helps match variable scope
to code block scope. Objects are variables bound to polymorphic
behavior behind typesafe interfaces.
Then I and many many others I know of use the term OO very
incorrectly.
The first time I'd heard the term "object oriented" was at a talk in
'82 about Simula. IIRC there was never any discussion about
polymorphism at that talk.
I subsequently defined a language named "clone" and wrote a compiler
for it that pushed the idea of state machines in control systems (the
state of the art at the time was ladder logic). It was "object
oriented" because it broke the monolithic aspect of code development
at the time. If you looked at the state of the art at the time, there
was very little in the idea of objects. Wirth's book, Data Structues
+ Algorithms = Programs was breaking new ground for crusty old
programmers.
The "class" (where the compiler enforced the "this" parameter) which
was the pivot point where languages enforced Wirth's premise and
started calling sturctures + methods "objects" and hence "object
oriented".
It seems like a rewrite of history to say that the pivotal moment for
OO was polymorphism. It seems to me to not be supported by the history
I know. I was one of the few programmers that created function tables
and to some extent had polymorphic C code. For example a generic AVL
balanced binary tree algorithm which was not dissimilar to std::map
(in function not form). It had iterators ! No-one told me that it
was any different to other parts of the system and the system was
referred to as "object oriented" at the time.
Besides, are templates not viewed as a "static" polymorphism ? In the
example, std::map, it may do use polymorphism, but it sure does
everything my (at the time) polymorphic AVL tree class did.