From: Buck
Joe Pluta wrote:
> This is the essence of polymorphism: call the same
> method for different objects and the underlying code
> will do what it's supposed to do.
How does one do that in RPG without IF or WHEN? My RPG experience and
habits didn't help take the concept to heart and become fluent creating
classes.
I'm not sure I understand the question, Buck. I'm not saying RPG is an OO
language, so it won't have those features. I'm saying that what we do as
human beings is essentially polymorphic; I buy a hot dog and I buy a house,
but the process is completely different for each one (I hope).
For an OO language, some serious magic occurs when it comes to resolving the
appropriate method to call. Polymorphism is perhaps the hardest thing to
emulate in a non-OO language, because you just don't have the appropriate
syntax constructs. The closest you might come in RPG would be to be able to
associate a specific service program with, say, a data structure, and then
be able to call the methods qualified based on the data structure; the
methods could have the same name in different service programs, and the
service program name would be used to resolve the method. The data
structure would then implicitly be the first parameter passed.
Actually, that would be kind of cool. And the New method would create a new
instance of the data structure... Hmm.
But I digress.
Reading the Javadoc and consuming a class is a lot like using
a service program's procedure in an RPG mainline, but building the
foundation classes so they can be usefully subclassed does not seem like
building an RPG service program.
And herein lies the point. There are two distinct classes of Java
programmers: class consumers and class creators. Anybody who teaches the
language needs to make this particular point clear from day one. Class
consumers are programmers like you and I, using the RPG language on a day to
day basis to solve business problems. Class creators are -- well, they're
Barbara, extending the language so that we consumers can use it.
And on a side topic, subclassing is far overrated, and the classes most
application level programmers might build for themselves are best done
through composition rather than inheritance, but that's a different
discussion for a different day.
Joe
midrange.com
