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