Re: CoBOL moved to OO

From: Richard (riplin_at_Azonic.co.nz)
Date: 01/08/04 

Date: 7 Jan 2004 19:10:54 -0800

Donald Tees <donald_tees@nospam.sympatico.ca> wrote

> >>How would anybody know? They refuse to try it based on theory based on
> >>other languages.
> >
> > What is this theory? What are these other languages upon which this theory
> > is based?
 
> Dmaned if I know.

It was your claim, now you say you've no idea why you claimed it ?

> However, I continue to read, on a daily basis, posts
> from peolpe inpthis group that have concluded OPP willnot work based on
> the fact they learnt it from (Java C++, fill in the language).

Which is really strange because I read all of this group and have
never seen that.

> I hardly
> think it unexpected, since most of them concluded that the procedural
> versions of the same languages were also unsuitable and would also fail
> (in some cases years ago).

or that.

> Sure. In fact, there are a whole class of programs that I would
> restructure using the OOP commands.
>
> Consider the traditional Cobol system based on a main menu, with each
> program being a subroutine, and the common setup data being read by the
> menu. Structurally, it normally looks as follows.
>
> Main program
> call read setup stuff
> menu loop
> choose program
> call program using setup-data
> end menu loop
> stop.

That is not how any of my systems have worked at all. I do have menu
programs but they are not the 'main loop' but are merely selection
programs that are used when other, better, means of selection fail.

> In addition, there will be many standardized methods set up as
> copybooks, normally one for working storage and one for the procedure
> division. Either that or a bunch of standard subroutine code.
 
> It makes far more sense to organize the same system as follows.
>
> system object.
> setup stuff
> read-setup method.
> run menu method.
> invoke self read-menu method.
> menu loop.
> choose program
> invoke program-method.
> end menu loop
> stop
> common method one.
> common method two.
> program method one.
> program method two.
> etc.
 
> The only real changes made to the old programs at all would be to change
> the program-id to a method-id, add a start-method and an end-method
> statement to the ends of each, and copy them into the new object as a
> copy statement.

This doesn't 'make far more sense' at all. You are building the whole
system into one huge lump of source code that gets compiled all at
once. The antithesis of OO design.

You have also lost all the dynamics from the system, taking it from a
flexible modular system into a fixed static monolith.
 
> The menu would have to change each "call name using" to a "invoke self
> "name" using"

> If you simply do that, you gain arguement checking for all system stuff.

That's no gain at all for a working system.

> However, if you want to go further, you can.
 
> Since the setup data is now up at the top of the main object, in it's
> own working storage, you could eliminate all the passed arguements
> completely. Just eliminate the using statements and the linkage sections.

That is hugely retrograde, why not go further and dump the ID and WS
sections and just PERFORM instead of invoking ?