Re: Future of RPG

On Tue, 9 Nov 2004 11:46:31 -0600, Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx> wrote:
> I find this argument a little out of kilter.  Many of the issues you are
> bringing up are not language-specific, especially in a multi-lingual
> environment like ILE.  They are OS issues, and handled quite nicely in
> ILE (better than most other OS's, in fact).

> 
> Exceptions can be signaled to any point in the stack (unlike the "bubble
> up one" of most exception-oriented languages).  This is EXTREMELY
> powerful.

it is also a violation of the principle of modularity.  A proc/module
should not know that 4 levels up is the driver CL at which all
exceptions are caught.  A module throws an exception back to its
caller.  It is the callers responsibility to promote that exception or
to handle it.

> 
> You can easily hook the job end exit point and provide whatever
> finalization your job needs.  While it's not handed to you on a silver
> platter, it's much nicer than, say, Java, where canceling the JVM aborts
> any finalization.  With ILE, I can do an ENDJOB *IMMED, and my
> end-of-job routine STILL gets invoked.

So the degree of granularity is the Job? That is not an acceptable
solution when you want to hide exception handling from the end user. 
Why should the user have to sign back on because my program failed?

> 
> Destructors are only required for garbage-collected languages, and while
> garbage collection is a nice-to-have especially for OO languages, it's
> certainly not necessary.

I dont think that is true and besides, that example limits the work of
a destructor to memory management.

>  We got along just fine without them in C, and
> wrote some pretty bullet-proof code.  It's a matter of registering
> cleanup code to be execute when the application ends, either normally or
> abnormally.  Of course, with ILE much of the system-level cleanup
> (locks, ODPs, overrides) can be taken care of for you when you end the
> activation group, which is what was intended.

What locks are released when the activation group ends?  A module
should not have to rely on an activation group boundary for it to
function properly. When the module invocation is destroyed on the
stack, that is when the destructors defined in the module should
execute.  What could be more simple than that?

> 
> There are many ways to skin a cat, and ILE RPG provides everything you
> need.  Just not necessarily the way you're used to.

Your arguing against the principles of modular programming. A module
is a self contained unit that functions properly regardless of
commitment control, activation groups, job exit points.   Exceptions
and destructors are what make that happen.

-Steve


> 
> Joe
> 
> > From: Steve Richter
> 
> 
> >
> > what I dont see mentioned in these posts is that RPG does not have
> > features that are critical to writing bullet proof modular code.  That
> > is, it does not have destructors, integrated exception handling,
> > struct member functions and base classes.
> >
> > A module has to be able to throw an exception when the inputs are not
> > what the module expects.   And since a module is going to call other
> > modules which may throw exceptions, a module has to be able to define
> > destructor code which will run in the event of an unhandled exception.
> > That is, code which will shut the module down in an orderly fashion (
> > close files, release mutex locks, free heap allocations ).
> >
> > -Steve
> 
> --
> 
> 
> This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
> To post a message email: RPG400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
> or email: RPG400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.
> 
>