[LC++]Generic programming vs OO inheritance

[Dan hursh]

  Oh, lets talk.  I was going to accept having you "almost convinced" 
until you went into that whole bit about all the information being
available at compile time for OO inheritance.  The time when polymorphism
(since that is what we are talking about here) is most needed is when you
don't know at compile time, what you will have. 
   This could be because of how the program is invoked (is stdin a file, a
pipe, a tty, a socket, etc), or you intend to use an object that behaves a
certain way but you don't know all there is about it.  (Is Ogg's sword
normal, is it a gag sword, does it have magical properties?  I don't want
to have a different Ogg for each possibility.  An Ogg who can hold a magic
sword, Ogg who can hold a normal sword, etc.  Magic is also not unique to
swords, so I would hate to have to repeat the magic code in swords, book,
wands, and candles.)  Polymorphism can come in handy for loadable
plugins.  I CAN'T know what might get plugged in.  If I need to know that
at compile time, I might as well go static.
    All of these things can and have been dealt with before OO, but if you
look at it, the file example is usually done by manually implementing
vtables in C.  The same is true of most pluggins now.  In the case of the
game, I want the character Ogg to have one weapon.  I'd either have to
have a since data type that can represent all of the possible object, and
have a flag that say a given instance is a weapon (which could waste a
lot space in each object) or I have to pointer point at an unknown object
and use a flag variable and a switch statement to figure out how to deal
with the object.  
    So yes, you could program around the lack of polymorphism at runtime
but you will usually end up implementing it yourself, or you will end up
using a datatype that can be all things at once and use it everywhere.  
    I will agree that with the exception of runtime binding (ala loadable
modules and pluggins) you will know what all the code will look like at
runtime with C++, but that does not mean you will know how it will be
used.  The OO inheritance will let you have a list of valious ostreams and
you could call operator<< in a loop (or even foreach if you want to mix
paradigms).  I guess that is the gist of it.  If the streams are opened
and inserted into the list according to user input at runtime, there can
be no way for the compiler to know how to build the list at compile time.
    Please don't take this wrong though.  I'm not flaming the use of
generics.  The are great and need to be explored more.  C++ support for
them could be made less painful.  They merely aren't the answer to
everything.  OO is.  (Ducks quickly.)  OK, OO isn't either.  OO is
probably oftem used where the behavior of generics would serve better and
that probably because OO being a buzzword and also because OO inheritance
is a little closer to how people generally think.  (It is an apple.  It's
also a fruit, a treat, and if throw right it's a weapon too.)
    What would be cool is if some template evaluation could be done a
runtime,  but I guess that would defeat the purpose of templates wouldn't
it.  It still might be nice a link time.

Dan

   
On Thu, 16 Aug 2001, Mark Phillips wrote:

> Dan hursh wrote:
> 
> > I think I'll also disagree with the statement "that with generic 
> > programming it would seem that the compiler can't do error checking 
> > nearly as well."
> 
> You've almost convinced me on this point.  Template "typename" (or "class") parameters give no information about the type of class which may be passed in.  This is in
> contrast to the OO base-class approach where the base-class effectively defines the type of class that pointers to this base-class are allowed to represent.  This is why I
> thought error checking would be 
> inherently worse with generic programming.  I still wonder whether there
> would be cases where this is true, but I think you are right that in the
> main it is not the case.  The "meta type" of template "typename" parameters
> is never defined explicitly, but implicitly it is, by use.  If somewhere
> the parameter is used as if it has a member function ".get()" for example,
> then this is implicitly saying that only classes which have this 
> member function get() may be used as a parameter.  The compiler should
> be able to detect this kind of error at compile time.  Indeed it does,
> though the error messages are fairly ugly.
> 
> Because the programmer does not have to _explicitly_ define the 
> "meta type" of "typename" parameters, it is certainly easier for them
> to make logical errors.  I wonder whether there might be clear examples
> of where generic programming is more error prone than OO, but I can't
> think of any.
> 
> 
> >         As far as the functional equivalence of generic programming and OO
> > inheritance, I don't think you can get the runtime behavior of OO
> > inheritance with gernerics without also use base-classes or implementing
> > you're own vtable-like structures.
> 
> I suspect that they are not completely equivalent.  What is true I think, 
> is that often the OO approach does at runtime, things that could be done at
> compile time.
> 
> I would be interested to hear an example of something which could be done
> with OO inheritance that can't be done with generic programming.  At the
> moment I can't think of any, but they may well exist.  I am guessing that
> you would need some kind of recursive definitions or something.
> 
> OO is mostly concerned with giving data individualized functionality: 
> member functions.  Because C++ does not allow self modifying code (in the
> strict sense --- templates allow the easy production of multiple code 
> variants), all functions will be determined at compile time.  The OO 
> base-class chooses between variant member functions at run-time, when
> in actual fact this information is available at compile time.  That is
> why the generic programming approach is superior in essence.
> 
> I don't think the full power of templates was realized when they were
> added to the language.  Because of this I think template implementations
> are a bit messy and clumsy.  However I suspect that before too long 
> someone will design a language with similar ideas, but expressed much
> more cleanly.  It seems to me that functional programming languages
> are not too far away from this.
> 
> Cheers,
> 
> Mark.
> _______________________________________________
> This is the Linux C++ Programming List
> : http://lists.linux.org.au/listinfo/tuxcpprogramming List
>