Subject: RE: CCL:Object-oriented means for computational chemist

From: "Smith JA (Jack)" <[email-masked]>
Date: Thu, 24 Jul 1997 09:52:29 -0500

-- Ping Du said:
> I found the discussions on OO programming very useful!  However, 
> there is a point that I would like to bring up.  That is, is it 
> possible to implement an OO design using a non-OO language?  The main 
> design features of OOD are abstraction, encapsulation, and 
> inheritance.  One may achieve abstraction and encapsulation in a 
> non-OO language by forcing discipline.  For example, use struct in C 
> as if there were classes and access data members through "interface" 
> functions.  However, implementing inheritance is impossible without 
> an OO language.  Inheritance is pobably the most important feature of 
> OO design if you would like your program to be extensible and 
> reusable.
   --

I'm finally glad to see someone make this point.  I've been wanting to
make the very same point, but I hesitated to get into the OO
programming/design/language debate when I've got so many other things to
do - like putting a C/C++ frontend to some really old FORTRAN (ANSI 66)
code!  ;-)

> - Jack
> 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>  Jack A. Smith             ||
>  Union Carbide             || Phone:  (304) 747-5797
>  Catalyst Skill Center     || FAX:    (304) 747-5571
>  P.O. Box 8361             || 
>  S. Charleston, WV  25303  || [email-masked]
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>

---

From: "Peter Shenkin" <[email-masked]>
Date: Thu, 24 Jul 1997 12:16:28 -0400

On Jul 24,  9:52am, Smith JA (Jack) wrote:
> Subject: CCL:Object-oriented means for computational chemist
> 	-- Ping Du said:
> > ... One may achieve abstraction and encapsulation in a 
> > non-OO language by forcing discipline....
> > However, implementing inheritance is impossible without 

> do - like putting a C/C++ frontend to some really old FORTRAN (ANSI 66)

All this is true.  However, there's another side to the coin.  Using
non-OO languages, like C and Fortran, one can assemble abstracted and
encapsulated libraries that can be called from a wide variety of
languages: C, C++, F77, F90, ....  It's true that you don't get
inheritance if you do this.

On the other hand, using C++, it's not possible to write a general-purpose
library callable from other languages, even if one writes a set
of interface routines that are type-specific, so that they avoid
name-mangling, etc.  Or so I'm told by those more conversant in C++
than I.  This is regrettable.  It means that once you start with C++,
you're stuck in a C++ world.  This is fine for many, but not all.

	-P.

-- 
**** "Deep Blue can't triumph in the game of life." (NY Times, 5/13/97) ***
* Peter S. Shenkin; Chemistry, Columbia U.; 3000 Broadway, Mail Code 3153 *
** NY, NY  10027;  [email-masked];  (212)854-5143;  FAX: 678-9039 ***
*MacroModel WWW page: http://www.columbia.edu/cu/chemistry/mmod/mmod.html *

---

From: "Peter Shenkin" <[email-masked]>
Date: Thu, 24 Jul 1997 15:48:49 -0400

On Jul 24,  2:27pm, Smith JA (Jack) wrote:
> Peter Shenkin[SMTP:[email-masked]] wrote:
> >On the other hand, using C++, it's not possible to write a
> >general-purpose library callable from other languages...
> >Or so I'm told by those more conversant in C++ than I.

> And now we're back to the mixed language debate 

> I find little problem with
> maintaining the overall system architecture and handling the user
> interface with a good application C++ class library, writing reusable
> non-computational 'modules' in plain C, and making use of (and even
> extending) existing FORTRAN libraries and program segments for the bulk
> of the computational work.

Your point is well taken, and I don't disagree.  On the other hand,
that's not quite the issue I was trying to raise.

The issue I was trying to raise is that regardless of whether one
wants to write the front end in C, C++ or Fortran, or anything else,
the language definition of C++ *precludes* writing a linkable code 
libraries in C++ if one ever wants to access the library routines 
from another language.  This is really too bad, because, whether 
it's optimal right now or not, OO techniques, including inheritance, 
are not inherently ill-suited for efficient computational methods and
even offer some advantages.  I'd love to be able to write some of these
underlying libraries in C++, but right now I cannot, because I
don't feel that I can tie the *users* of the libraries -- who may
not be limited to me -- to C++ exclusively.

	-P.

---

From: "Smith JA (Jack)" <[email-masked]>
Date: Thu, 24 Jul 1997 14:27:08 -0500

>On the other hand, using C++, it's not possible to write a
general-purpose
	>you're stuck in a C++ world.  This is fine for many, but not
all.

	And now we're back to the mixed language debate (I knew I
shouldn't have jumped into this!).  I find little problem with
maintaining the overall system architecture and handling the user
interface with a good application C++ class library, writing reusable
non-computational 'modules' in plain C, and making use of (and even
extending) existing FORTRAN libraries and program segments for the bulk
of the computational work.  However, if I could start all over, I'm
really not sure how much of the FORTRAN I'd rewrite in C/C++, or how
much of the C I'd promote to C++.  Since I (and most of us) don't have
the luxury of time to start over, I don't worry about it too much, and I
find the 'application class library'/C++/C/FORTRAN/'numerical subroutine
library' approach to be an acceptable compromise.  And I know I have a
lot company.

	- Jack