Strategic Java Usage/Productivity

["Nathan M. Andelin" <nandel@xxxxxxxxxxxxxxxxxxx>]

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.


----------------------------------------------------------------------

message: 1
date: Wed, 17 Mar 2004 11:11:23 -0800
from: "Paul Holm" <pholm@xxxxxxxxxxxxxxxxx>
subject: Strategic Java Usage/Productivity

Nathan/All

Thanks for the clarification of your points.

 The point I was trying to make is that Java and its OO capability can lead
to much much higher levels of productivity than procedural and RPG languages
in both utilities and application development projects.  I am not an RPG
expert so I might be missing something(s), please excuse/correct me if I'm
off.  The flexibility and productivity possible via inheritance,
polymorphism, frameworks, and interfaces would be very difficult or
impossible to match with procedural languages.

I agree that performance can be an issue with complex objects but that all
depends on the object/framework design in my experience.  Frameworks and
components; that's where I enjoy spending most of my time, especially since
I can't afford to golf daily which is my other passion</sigh>.  Inquiry
objects with inherited "maintenance" method for insert, update, delete, copy
can carry minimal overhead and the payback is huge in terms of programmer
productivity.

For example, I built and deployed, an additional inquiry operation which
returns a completely generic Java component with inherited but overridable
maintenance methods (insert, update, delete, copy) and it performs very
well.  This "department" inquiry was developed and deployed in 45 seconds
using  a set of Java components.  That's where I think AS400 shops and
others can benefit from OO and Java technology.

http://www.planetjavainc.com/wow60/runApp?id=298

Java methods are attached to the class so even multiple instances of the
components have much less overhead than people suspect.  For example, in
addition to the inherited maintenance methods, the framework/component also
inherits:  MS EXCEL, XML, web services, dynamic field level security and
validation, dynamic associations for linking files to other files, column
level sorting (black triangles), dynamic column headers, and several other
features.  All features inherited, customizable, to any database, on any
platform with zero programming effort needed; all in 45 seconds.

That's what Java and OO/frameworks can provide.

As far as the XML to HTML performance,  I haven't worked with it too much
but I imagine having to parse and regenerate the UI on the fly could be
expensive;  I don't know enough about that to comment.  Have a good ne.
-Paul Holm