RE: CEETSTA API -- RPG400-L


On Thu, 28 Aug 2003, Bartell, Aaron L. (TC) wrote:

> >I don't see how that solves the problem?   Unless you wanted to write the
> same code twice, that is.
>
> The example you gave at the bottom of the program is what I am talking
> about.  Instead of getCust(nbr: *Omit) and getCust(*Omit: 'John') you would
> create getCustByName and getCustByNbr.
>

That's nice, but unless one or the other allows an *OMIT variable, you
have to write the code twice (once for getCustByName and once for
getCustByNbr)

If you use an *OMIT style option, or something that can be defaulted, etc,
etc, you can write the code once.   Sure, you can have each of them call
a "private" (non-exported) function for the common code, but then THAT
function needs to have an *OMIT style option.   In any case, you need
that capability, overloading doesn't solve the problem.


> I think implicit type casting would solve the above problem, but I am
> guessing you would still have a beef if we could create our own objects in
> RPG and the difference between two same-named sub procs would be that they
> accepted different types of objects.  I think this would be very nice when
> used appropriately.

Sure, inserting a (short) to cast my int to a short solved the problem,
once I figured out what was going on.   But, it didn't even occur to me...
The compiler error was that it couldn't find the procedure/prototype that
I was trying to call.   If it had told me that it was a type mismatch I
could've solved the problem easily.

But, because of overloading, it doesn't know whether I specified the
wrong procedure, or if I forgot to code the procedure, or if I specified
the wrong variable type, or if I needed to do a cast.   It just knows
that it can't find a procedure called "getCust" with a parameter type of
int.   So, it says it can't find the procedure, when the real problem was
that I specified an int instead of a short.

>
> Well written overloaded sub procs will not have much if any duplicate code,
> IMO.  You put the reusable pieces of code in non-exported sub procs that can
> be used by all of the GetCust overloaded methods.
>

There are circumstances where things are simple and you don't need to
duplicate code, I'll grant you that.   But there are also more complicated
circumstances where you have no choice unless you code yet another
procedure that does have an *OMIT parameter.  (or some other way of
specifying "dont use this")

>
> >I don't like having to specify a "mangled" name when creating binder
> source, or when using %paddr().
> Not sure what you mean here.
>

Well, if you've only worked in Java, you wouldn't understand.   In Java
procedures are located based on the types of variables passed to them...
Java doesn't look for a procedure called getCust().  Instead, it looks
for a procedure called getCust(int) (assuming the only arg was an int)

But, in RPG that would break things.  When you do a %paddr('GETCUST') you
wouldn't know whether it was looking for getCust(int) or getCust(String).
So, instead you'd have to mangle the name.  The compiler would see a
procedure called getCust(int) and would rename it (in the compiled
object only) to something like, maybe, getCust@i, and it would rename
getCust(String) as getCust@s  (or some other method of renaming them so that
they'd be unique for each possible parameter type)   This is commonly
referred to as "mangling" the name -- and is the way things work in C++.

If you DIDNT do that, then you'd have to change the rules for the way
that RPG searched for procedures when the call is made to add the data
types to the search as well as the proc name, and that would probably
break existing support for subprocedures, not to mention that the binder
source would have to have parameters added to the EXPORT entries in order
to allow them to work, and all existing binding source would have to be
rewritten.   I don't think this way -- the Java way -- is likely to
happen.  Not unless we switch to RPG V.

> I think they should be added, and if you don't like them then you can go and
> camp out with Joe in the "un-useful RPG enhancements" camp :-)
>

If they allow overloading in a way that it can be "turned on" and "turned
off" individually for each procedure, then fine, I don't have a problem
with it.  In fact, I'd even welcome it.

But, if it becomes something you must turn on in a "per program" basis, or
a "per release" basis (by doing object conversions like they did from
CISC to RISC) then I'm not going to be happy with it.  It needs to be an
optional feature that's specifically enabled for certain procedures
only.   Maybe a "MANGLE" keyword on the D-spec :)