Xref: utzoo comp.lang.eiffel:471 comp.lang.c++:5288 comp.object:306
Path: utzoo!attcan!uunet!wuarchive!mailrus!jarvis.csri.toronto.edu!rutgers!pyrnj!esquire!yost
From: yost@esquire.UUCP (David A. Yost)
Newsgroups: comp.lang.eiffel,comp.lang.c++,comp.object
Subject: incremental conversion from C to OO
Message-ID: <1530@esquire.UUCP>
Date: 28 Oct 89 04:01:55 GMT
Organization: DP&W, New York, NY
Lines: 92

Consider the case of a large existing C program that is
being maintained and extended.  Now one gets the idea
to migrate the program incrementally to an OO language.

Here are some alternatives:

I.   Languages-by-C-extension, such as C++ or Objective-C:

     No muss, no fuss.  Simply switch to the new
     compiler, start using the OO features here and
     there among the existing code, and before you know
     it, presto!  You have an OO program!

     (Seductive.  But will you respect yourself in the
     morning?  You've bought into a language that put
     compatibility above all, that held on to all the
     complexities of a low-level language and
     compounded them with the complexity of OO features
     struggling to coexist.  I think it's high time for
     a clean, please-make-it-incompatible, higher level
     language.  At some point you have to let go of the
     details to move up.  Remember when we migrated
     from assembler to C?  Remember all the low level
     control we gave up?  Just as we let go of register
     allocation, so must we now let go of memory
     allocation (for example).  I love to ponder our
     fate if instead of C, Bell Labs had given us a
     language called, say, "incr_asm".  Then imagine
     extending that language to be OO.  Wow, full
     control!  It's like a CEO trying to do all the
     jobs in a big corporation all the time.)

II.  Non-C-derived languages such as Eiffel:

     Link the existing C code with external code in
     the new language.

     A.  Using vanilla C:

	 Using external objects is notationally ugly,
	 and you have to live without some or all of
	 the benefits of type checking, exception
	 handling, garbage collection, etc.

     B.  Using a compatibly extended C:

	 I am suggesting here a preprocessor for an
	 ANSI C superset language that would have
	 enough extensions to manipulate objects
	 maintained in Eiffel (as a client, not a
	 parent or heir) and would possibly also
	 transparently insert code for example, to
	 support exception handling in the Eiffel code.
	 In effect, you would be extending C to make
	 available more powerful types, (which can be
	 garbage-collected, can handle exceptions,
	 etc.) but you would leave to Eiffel the
	 implementation of those types.  The Eiffel
	 environment could even keep track of the
	 external type declarations without the need
	 for header files in the C code, much as Eiffel
	 now works within its own code.

I like the idea of this last approach because it could
allow you to migrate a large program slowly to a new
language without the need for that language to also
serve as C or for C to try to be a full-blown OO
language.  To convert, one might slowly change the C
program by a mix of these strategies:
  * using library objects from the OO side
  * moving large blocks of functionality from the C
    side to the OO side

Now we raise the question: is it really a good idea
to try to migrate an existing program to OO or is it
better (quicker, more maintainable) in the long run
to redesign from scratch in the new language using OO
design?  (If the latter is true, then it is all the
more clear that there is no contest between a cleanly-
designed higher-level OO language and a compatible C
extension.)

It is an attractive notion (though short-sighted) to
simply switch a program to C++ or Objective-C and start
getting the benefits of OO right away, but does it work
so smoothly in practice?

Would some experienced hands out there tell us the
good, the bad, and the ugly about real experiences
migrating existing code to OO?

 --dave yost