Re: Java is becoming the new Cobol



"Richard" <riplin@xxxxxxxxxxxx> wrote in message
news:dd4626b6-fea1-448c-9fb0-d7cf7cf25770@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Jan 7, 3:20 am, "Judson McClendon"

Had that code been already written procedural code, with comparably
strict
definition and usage attributes, you would have been in the same
situation.

C++ solved for C many problems which did not exist in Cobol, nor in
applications typically written in Cobol. In fact some of these
problems in C had been solved for years in Cobol (such as by dynamic
loading of modules).

If the problems which OO solves are not problem to a Cobol application
then there is no need to use OO.

However, OO in Cobol does provide one feature that cannot be done
easily other ways and that is that they may be multiple objects,
wheras a module implementation only naturally allows a single use.

For example I developed a 'raw output' module for an application I was
converting to Fujitsu. The application had HPLaser commands built in
(I didn't write it) wheras Fujitsu generates postscript.

Implementing this as a module did the job fine, but one program needed
two streams. To change the module to handle two outputs would have
required a great deal of work. Or I could have just generated a 2nd
module from the same source and used different call names.

But using the OO implementation just required another 'new' and just
worked correctly.

If the applications that you design will never need multiple objects
(because it is designed around the limitations of procedural code)
then you will not see the need or use of OO.

As you have noted before, Richard, we are all comfortable with what we are
familiar with. I think your last paragraph is on the button.

Pete.
--
"I used to write COBOL...now I can do anything."


.