• Subject: Re: Overloading in RPG.
  • From: boldt@xxxxxxxxxx
  • Date: Wed, 9 May 2001 08:41:55 -0400
  • Importance: Normal


Jim wrote:
>Overloading is purely an OOPS thing, and you could do the same thing with
>*OMIT or *OPTION in RPG, although not exactly the same.

then Aaron wrote:
>Agreed.  I have this new thirst since I have started coding in Java.  Java
>definitely has some cool features that I think are within the reach of
RPG.
>Will the RPG group ever look at overloading?  Hans?


You really want my opinion?  Well, you asked for it!  (If you want a
quick answer, skip down to the "bottom line" below.)

First off, overloading has nothing to do with OO.  Some OO languages
(like Java and C++) have special rules for overloading, other OO
languages (like Perl, Python, Object Rexx, Smalltalk - ie. the "good" OO
languages) don't.  Furthermore, there's no reason you can't have
overloading in non-OO languages.  C++ can (and often is) programmed in a
procedural manner, and overloading can still be taken advantage of.

Is overloading a good thing?  Well, that point is certainly debatable.
To answer that question, let's look at how my favorite language, Python,
and the other interpreted OO languages, handle overloading.  In those
languages, basically, everything is an object.  Since everything is an
object, and method parameters are basically of one type, object, the
concept of overloading is both implicit in the language and of no
consequence whatsoever.  What you can do with particular objects is
determined solely at run-time.

The way compiled languages do overloading, on the other hand, is
typically a consequence of the compilation process, because it makes the
difficult task of compilation easier.  Compiled languages tend to be
strongly typed, not just to help ensure program correctness, but also to
be able to generate efficient code.  (The former is often more of a
convenient excuse for the latter, rather than a noble goal, in my humble
opinion.)  In compiled languages, overloading is achieved through special
syntax and semantic rules because of the strong typing in those
languages.  Strong typing, to a great extent, really goes against the
grain of OO philosophy.  And so, special rules for syntax and semantics
have to be grafted on top of the languages in order for these languages
to behave sort of like the real (interpreted) OO languages.  A direct
result of these rules is the persistent nuisance of always having to
cast the types of object pointers in compiled OO languages.

(BTW, regarding Java, I've always said that Java is a language that
combines the disadvantages of compiled languages with the disadvantages
of interpreted languages.)

Did that make any sense?  No?  Well, who cares!

What about RPG?  RPG may never become fully OO, but then that's a
different question than overloading, isn't it?  Overloading of procedure
parameters may well come about when (or rather if) the different IBM
sites involved (at least three at last count) can get their acts together
and enhance the operational descriptor support in the system.  In that
scenario, RPG would have a "don't care" type for reference (and perhaps
const) parameters, and the programmer would be responsible for
determining type of parameter and taking the appropriate action depending
on the type.

BOTTOM LINE:  Overloading in the style of Java or C++ I don't see in RPG
due to the complexity of implementation compared to the benefits.

Cheers!  And have a good Wednesday.

Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.com

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.