Re: Need some advice

By the way, I think this is why the whole OVRxxxF stuff works - you can make printed output go to a PF and vice versa - because the methods are the same name, just in a different overlaid class, say.

I know - lots of things probably wrong with my analogy here - but it helps me, at least a little.

Another thought - PFs have components, each of which is another "class" - formats, members, indexes.

-------------- Original message --------------
From: vhamberg@xxxxxxxxxxx

I think we work in object-oriented ways more than we know. For one thing,
consider the object-based design of the S/38 - AS/400 - iSeries - i5 and you
will have some groundwork. E.g., a *FILE object could be considered a class - I
know, it's deeper than that, but let's keep this simple - am just forming this
on the fly - and a *FILE object has certain attributes at what we call
file-level (file level identifier os one). ALL *FILE objects have these same
attributes.

Now on the iSeries there are also methods contained in every object - things you
can do - you can't write to a *PGM but you can to a *FILE.

Then you get a subclass, PF is one, DSPF is another, PRTF another. These all
inherit the attributes and methods of the parent *FILE. Then each one adds
attributes and methods and perhaps puts in a subclass-specific version of
methods that are called first, maybe.

With PFs you can get further subclass of SQL table - and on it goes.

In our programming, as soon as you get into service programs and subprocedures,
you are starting to talk about separating routines - you may even be setting up
variables and using setters and getters for various things - you CAN do OO
programming in any language, it's just easier in a language that supports it.

HTH and does not confuse too much! And hope it is a little on point!
Vern

-------------- Original message --------------
From: Pete Helgren

Phil,

I probably should restate the "the basics of programming that you use
every day in RPG will serve you well" then.

What I meant was that things like variables, arrays, loops, calculations
and many of things things we are familiar with in a procedural language
are also present in Java so making the transition from a "for loop" in
RPG to a "for loop" in Java wasn't that difficult for me (for example).
Where I had issues was in designing classes and methods that were truly
objects. I was doing some heavy mental gymnastics in thinking in
objects and I STILL have issues when I design classes as to what should
be an abstract class vs an interface vs a "regular" class. I move more
comfortably between RPG and Java now but I still trip over the object
stuff from time to time.

So it was the very basic "programming concepts" that were easy (to me at
least) to move to Java. Designing an object that contained both data
and processes for managing the data within the object was the hard jump
for me to make.

Pete


Phil Kestenbaum wrote:

Pete, How would you describe the RPG background as serving well in
object oriented programming? When I was studying this, I instinctively
was trying to make this connection, unsuccessfully.

Thank you,
Phil