From: lwloen@rchland.vnet.ibm.com (Larry Loen)
Subject: Re: What is Object Oriented Programming? Is C doomed?
Date: Tue, 15 Dec 1992 20:01:31 GMT
Reply-To: lwloen@rchland.vnet.ibm.com
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM Rochester

In article <id.S2UV.VMK@ferranti.com>, peter@ferranti.com (peter da silva) writes:
|> In article <Bz4ro7.3w3@cmptrc.lonestar.org> tmike@cmptrc.lonestar.org (T. Mike Howeth) writes:
|> > For these reasons, I DO suggest utilization of the OO design and coding
|> > practices in other environments.
|> 
|> I can't agree more. In fact, the difference between a well designed software
|> component in any conventional language and a well designed object in an
|> object oriented language should be pretty darned near epsilon.
|> 
|> > Absolutely!  It disappoints me that OO critics (such that they are) suggest
|> > that the Tao of OO is nothing other than formalized, restrictive coding
|> > standards.
|> 
|> No, it's formalised software design. It's got damned little to do with coding
|> at all.
|>

Well, yes and no.  See below.
 
|> > |And these techniques really require an OO
|> > |language for their implementation.
|> 
|> I don't buy that argument. A well designed OO language can sure make it
|> easier, but it's no more necessary than a structured language is necessary
|> for structured programming.
|> -- 
|> %Peter da Silva/77487-5012 USA/+1 713 274 5180/Have you hugged your wolf today?
|> /L{lineto}def/C{curveto}def/F{0 562 moveto 180 576 324 648 396 736 C 432 736 L
|> 482 670 518 634 612 612 C}def/G{setgray}def .75 G F 612 792 L 0 792 L fill 1 G
|> 324 720 24 0 360 arc fill 0 G 3 setlinewidth F stroke showpage % "Peerless"

Oh?  Have you really looked at it?  Maybe it is easy to do it in C, but I can
think of lots of languages out there that people still use that would make it
darn near impossible to do decently.

In particular, what about overloaded functions (ie, methods with multiple
signatures)?  True, you can fudge by without them, but they are a very handy
and logical extention of the OO paradigm.  This is especially true for
constructors.  And, having Blue_Constructor and Red_Constructor and so forth is
also a conceptual mess if you don't have overloading.  But, not all languages 
allow overloading of any kind, keep in mind.  C++ has a lot of that stuff to
make OO productive and conceptually sensible.

Polymorphism can be done, by hand, in many languages, but it is an error-prone
pain in the neck.

And, another thing too easily glossed over is C++'s automatic construction of
temporary objects in various guises.  When you remove that and do it all,
yourself, by hand, it can get very messy and complicated to do.  Doable?  Sure,
but what a waste of human intelligence!  The list can be quickly multiplied.
What about type conversions, for instance?

I don't think too many people are willing to pay for hand implementation of
OO technology, though there are probably a few out there doing it.

I agree, however, that one can do an OO design without OO implementation.  But,
that gets kind of tricky because the sensible way to implement it is to try and
do it without objects (ie, make them dumb structures instead, benefitting only
from the improved decomposition).  It also seems like settling for half a loaf.
The other alternative is doing OO by hand, which I've already described.

There are many things that are possible, but they are also neither necessary
nor prudent, except in exceptional circumstances (mainly, the unavailability
of a suitable compiler).

I remember some very brief experiments to permit "structured" assembly 
language programming and the like.  Such kludges were abandoned relatively
quickly and seen as the transitions they were.  Doubtless, some poor soul will
post "hey, I'm still doing that", but the industry as a whole left it behind
about as quickly as could be managed.  And OO is a lot more of a leap than
structured programming over goto-ridden was.

In brief, I agree with you in principle, but not in practice.  One's tool set
does matter.

-- 
   Larry W. Loen        |  My Opinions are decidedly my own, so please
                        |  do not attribute them to my employer
Newsgroups: alt.amateur-comp,comp.lang.c,comp.lang.c++,comp.misc