Re: Strategic Java Usage/Productivity

["David Morris" <David.Morris@xxxxxxxxxxxxx>]

Nathan,

I just searched for an article I wrote for Midrange Computing that
describes how to build a simple RPGIV component for dynamic data
access.I created a simple version for the article based on one I wrote
for another company. The full version does support native access and
file updates (including recursive and trigger-driven updates).  It took
several hundred hours to write and several thousand lines. I used the
Mediator design pattern along with meta-data to describe the data model
and to attach business logic. Overall, it worked very well. 

That full version of the I/O Mediator is the most useful program I have
ever written and there is a chance I could get someone to allow me to
release the source. At this point, I don't write much RPG and I miss
having the ability to encapsulate business logic in the database layer.
I have been biding my time waiting for trigger performance with Java to
come up to speed. At that time I will rewrite the original version in
Java because it is a much better fit for this type of programming. The
original version required quite a bit of pointer gymnastics to provide
local storage for data and to cache meta-information.

I searched and that article is still available at 

http://www.mcpressonline.com/mc?50@xxxxxxxxxxxxxxxx@.214a309b

David Morris

>>> nandel@xxxxxxxxxxxxxxxxxxx 03/18/04 12:36 PM >>>
Paul,

Your file maintenance utility has inspired me.  I'm considering writing
a
generic component in RPG, not for maintaining, but for browsing files. 
I
can envision exporting an api such as the following:

 fileReference = browseClass_Open(Library:File:Member)

 browseClass_SetFileReference(fileReference)
 browseClass_ListFromTop(recordCount)
 browseClass_ListNext(recordCount)
 browseClass_ListPrevious(recordCount)
 browseClass_ListFromBottom(recordCount)
 browseClass_ListFromKey(key:recordCount)

 ...

 browseClass_Other()

I don't think I'd want to bite off generic add, change, and delete
procedures, because such actions are generally subject to complex
business
rules that would need to be overridden and adapted to individual
circumstance anyway.

There are more similarities between ILE and OO languages than most
people
realize.  For object instantiation in RPG:

 Eval myInstance = myClass_New(parameters)

 Callp myClass_doSomething(myInstance: parameters)

Where myInstance would be a pointer to a data structure containing
instance
properties, which would be referenced from myClass procedure calls.

For inheritance in RPG, create a new module, either importing and
wrapping
the procedures in a base module, or create a new module containing just
procedure overrides, then bind to both modules.

For polymorphism in RPG, define data exports in modules, supplementing
procedure interfaces, which alter the behavior of procedures based on
data
content.

It's true that most RPG programmers wouldn't consider following OO
design
patterns, unless they first immersed themselves in OO languages for a
period
of years.  But I returned to RPG for both performance as well as
productivity reasons.

Nathan.