Xref: utzoo comp.lang.eiffel:478 comp.lang.c++:5312 comp.object:327
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!cs.utexas.edu!usc!rutgers!att!cbnewsc!jwd
From: jwd@cbnewsc.ATT.COM (joseph.w.davison)
Newsgroups: comp.lang.eiffel,comp.lang.c++,comp.object
Subject: Re: incremental conversion from C to OO
Message-ID: <4232@cbnewsc.ATT.COM>
Date: 30 Oct 89 22:28:27 GMT
References: <1530@esquire.UUCP>
Reply-To: jwd@ihlts.ATT.COM (joseph.w.davison,55515,ih,6n503,312 979 4920)
Organization: AT&T Bell Laboratories
Lines: 70

In article <1530@esquire.UUCP> yost@esquire.UUCP (David A. Yost) writes:
>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
 ...
>II.  Non-C-derived languages such as Eiffel:
>
>     Link the existing C code with external code in
>     the new language.
 ...
>     B.  Using a compatibly extended C:


	Why not use C++ or Objective C in THIS manner?  They're
already extended enough to define the classes you need.  So, build
a class EiffelObject and tie it to Eiffel...

>
>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?


	Well, It depends on how rich you are, and how long your
customers are willing to wait.  If the "Legacy" (the system that has
been handed down and needs to be migrated) took 5000 Staffyears to 
get to where it is now, even if the answer to the question is obviously
YES, it IS better, and it IS more maintainable.  And even if your
productivity enhancement in switching to GOODS (the Great OO
Development System) is at least 10, the task may still be 500
StaffYears.  OK, you're going to do even better -- take another factor
of 10.  Can you and your customer affort 50 Staffyears?  (How about for
systems 10X larger?  100X? )

	I suspect that for LARGE systems one wants a hybrid approach, where
one can identify subsystems that have not been changing much in recent times,
and they can be left largely intact, using approach I where necessary.
Other subsystems will have been changing much more rapidly.  Those I
would consider doing a full redesign, and use approach II to connect to 
the old system.  

If one considers the issue from an Analysis of Algorithms viewpoint, I
think you will find that, just as in sorting, the optimal way to solve
the problem depends on the size of the problem. 

>
>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?
>
	Somehow, changing compilers doesn't seem like it's going to
make major improvements...

-- 
 Joe Davison      jwd@ihlts.att.com