Re: Using STATIC

Hi Joe!  You've brought up some interesting issues!

Joe Pluta wrote:
> 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.

First, well of course, in a distributed environment data is pretty
much "hidden" to begin with.

But in general, "object hiding" is a funny concept.  Some languages
like Java provide strictly enforced rules for accessing the elements
of an object using keywords "public", "protected", and "private".
C++ offers these keywords too, but then again, how many C++
programmers remember to code "#undef private #undef protected" at
the beginning of their .hpp files?  ;-)

And then some OO languages count on convention to "hide" data.  For
example, in Python programming, programmers use the convention that
names beginning with "_" are private.  As long as everyone
understands and follows the convention, then everything works fine.
In other languages, by reading the module and method prologs, you
can find out which elements are public and which are private.

The important OO concept here is not really the "hiding" of data per
se, but rather the "encapsulation" of data.  A simplistic definition
of object is that it is a set of data combined with a set of methods
for dealing with the data.


> 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.

And as you've illustrated nicely, this gets very messy very quickly.
It simply moves the "select" statement from the caller to the base
class.  If you want to add a new sub-class, you still have to add a
"when" clause to that "select" group.

OK, it can make maintenance a bit easier, but I believe this just
adds support to my assertion that if you want to implement an OO
design, you should use an OO language.


>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.

I'm not really sure what you mean by "strict OO design".  The
definitions for what is an OO language usually refer to things like
encapsulation, polymorphism, and inheritance.  Not all OO languages
implement them all in the same way, and so some people argue whether
or not particular languages are really OO.

Anyways, I do see your point about adding methods in subclasses.
When you do that you tend to move away somewhat from polymorphism in
your design.  And in OO languages with compile-time type checking
(like Java and C++), you end up having to up-cast your object
references.  Lots of up-casting does seem to be a characteristic of
bad OO design.  (Languages with run-time type checking allow you to
avoid up-casting, but that doesn't necessarily make your design any
better!)

On the other hand, adding methods to sub-classes is what happens
when, for example, you implement particular interfaces in a Java
class.  And, some OO languages even provide you the flexibility of
adding attributes and methods to particular objects at run-time. The
concept of "mix-in" classes is common in some languages.  Having the
ability to add attributes to particular instances at run-time spares
you the trouble of defining sub-classes.

Perhaps by "strict OO design", you're referring to the concept of
"design patterns"?  The ideas behind "design patterns" are indeed
very powerful, and is definitely worth studying for anyone
interested in learning OO.  But it is also important to understand
when to apply the patterns and when not to.  Furthermore,
implementation of the patterns is somewhat dependent on
implementation language.


> 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.

No argument there.  As RPG programmers use procedures more and more,
and share their procedure libraries more and more, eventually, the
RPG community will run into problems with namespace collision.  So,
the language (and probably the O/S) will need some syntax to be able
to include some set of external names, but with a specific local
qualifier.  For example, then one module could include procedure
"glorp" from module "abc" and also a different procedure "glorp"
from module "xyz".


> 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.

Funny, I see lots of examples in books of business logic implemented
using OO models.  On the other hand, I do see your point.  Business
logic tends to be tied in very closely with a database.  Although
there is lots of hype about "object-oriented databases" (and other
supposedly better DB systems), the reality is that the (32 year old)
relational database model is *still* the best we have.  Merging a
relational database design with an object-oriented design can be a
non-trivial impedance-matching problem, especially with older, non-
normalized databases.

Still, with a bit of thought, and a proper relational database
design, you can easily come up with ways to map persistent objects
to rows in your database.  I've even noticed that, to some extent,
inner joins can be used to simulate polymorphism.

Cheers!  Hans