× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I am not sure what you mean by "inadvertently using it".  When you looked at
the API docs you saw a getCust sub proc that could be passed an alphanumeric
field or an integer.  Upon seeing the options you decide you want the
integer one because that is all you have at the time in your program. . .

You might have to set me straight here.

Aaron Bartell

-----Original Message-----
From: rob@xxxxxxxxx [mailto:rob@xxxxxxxxx]
Sent: Thursday, August 28, 2003 4:51 PM
To: RPG programming on the AS400 / iSeries
Subject: overloading was RE: CEETSTA API


Scott's point might be that after they add it you have little choice as to 
whether or not you use it.  You may end up using it inadvertently.  As I 
did with my experiences with UDF's and stored procedures.

Rob Berendt
-- 
"They that can give up essential liberty to obtain a little temporary 
safety deserve neither liberty nor safety." 
Benjamin Franklin 





"Bartell, Aaron L. (TC)" <ALBartell@xxxxxxxxxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
08/28/2003 04:24 PM
Please respond to RPG programming on the AS400 / iSeries
 
        To:     "'RPG programming on the AS400 / iSeries'" 
<rpg400-l@xxxxxxxxxxxx>
        cc: 
        Fax to: 
        Subject:        RE: CEETSTA API


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

<Scott>
I won't.  I don't like overloading.  I think it's confusing when the
compiler gives you an error "procedure not found" and the reason turns out
to be that one of your variables is a "short" and the procedure was
expecting an "int".   That's not intuitive.
</Scott>

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.

<Scott>
I don't like it when I search a program for a procedure called "GetCust"
fix a bug in it, and it has no effect because there's more than one
procedure called GetCust.
</Scott>

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.

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


>The problems of overloading far outweight the minor difficulties of 
making
procedure names like "GetCustByName" instead of "GetCustByNumber"

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 :-)

Aaron Bartell




_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

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.