RE: Using STATIC -- RPG400-L

> From: Hans Boldt
>
> What you've described is more appropriately called "object-based",
> and not "object-oriented".  Although it may well "mimic" some
> aspects of OO behavior, you still haven't accounted for things like
> polymorphism and inheritance.  Without those things, you just don't
> get most of the advantages of true OO.

Yeah, but you do get object hiding, which is all I was trying to get at.  If
you have lots of time on your hands, you can also incorporate polymorphism
and inheritance, which is simply a matter of using a method table based on
object type - no more, no less.  There's nothing "magic" about OO, it's just
programming.

Of course, I wasn't trying to do that, I was just trying to hide the
contents of the structures to avoid side effects, which is one very powerful
advantage of OO programming.  Not the only one, to be sure, but one very
powerful one, especially in distributed programming environments.


> For example, in an OO design, you can have two objects that both
> implement method "glorp".  When you apply method "glorp" to one
> object, it might have one particular effect, but applied to the
> other, something different might happen.  But (hopefully) in either
> case, a "glorp" action appropriate to the object would happen.  The
> caller doesn't have to understand how it works, or rather, which
> particular implementation is invoked.  The caller only has to know
> that the object is "glorp-able", and just has to invoke it using
> some direct syntax like "obj.glorp()", instead of by using a big
> "select" statement with a "when" clause for each type of
> "glorp-able" object.

An excellent introduction to the concept of polymorphism.  While that's not
what I was suggesting, it can be done.  It's actually pretty easy to do this
in RPG. And I wouldn't use a when clause - with method tables, you wouldn't
need anything like that.  Are you familiar with procedure pointers and how
to use them?

Simply put, each "method" in the "class" (that is, each procedure in the
service program) is actually a dispatcher.  Methods in the class are stubs
which in turn check to see if there are subclass overrides.  This can be
done dynamically by class or statically by attaching a method table to each
object.  The tradeoff is runtime overhead vs. object creation overhead.
It's your choice.  But the application programmer doesn't care, he just
invokes:

    glorp(obj, parm1, parm2)

The glorp stub then determines which true glorp method to call.  There are
places where this has problems, primarily involving multiple inheritance,
but for most purposes it's fine.  It also gets stickier when you have to
deal with added methods in subclasses, but that's actually a no-no in strict
OO design.

And those problems could be gotten around if the RPG language had been
designed to allow qualified procedure naming.  With that, we'd be able to
easily implement the stub programming I've outlined.  All we'd need
something like this:

    pModule.procedureName(parms...)

Where pModule is a pointer to a module.


> Might it be possible to "simulate" true OO behavior in RPG in *all*
> its glory?  Well, I've tried to come up with a design for it, and
> have given up on it, quickly.  But then again, why bother when there
> are so many other good *truly* OO languages available?

Yup, this is overkill in an RPG environment, because application business
logic doesn't lend itself nearly as well to polymorphism as does something
like UI programming or compiler generation.  This is due to the more
changeable nature of business rules.  But that's been the problem all
along - trying to use one tool for all business issues.  I don't use RPG to
create HTML, and I don't use Java to write business logic.

Joe