|
midrange.com
Hey Carel,
On Fri, 2003-10-17 at 21:30, Carel Teijgeler wrote:
> I wrote:
> >Just some thoughts on this:
> >How are you certain that this (overloaded) procedure getName will return the
> >correct name? If two procedures expect a numeric value >and you pass a
> >numeric value, will the first procedure not accept the "call" and return
> >its found name? the similar problem applies to >character values. Just
> >wondering.
The rules of overloading dictate that each signature must be unique, so
you cannot have:
getItem( myNumber ); // Invoice SRVPGM
getItem( myNumber ); // Inventory SRVPGM
You are right, there is no way for the compiler to determine which one
to use because the signatures are identical. That's why I suggested the
possibility of qualified procedures:
INVOICESRV.getItem( myNumber );
INVENTSRV.getItem( myNumber );
> Buck wrote:
> >Hi Carel! Great question! In my quick typing, I hadn't thought to include
> >the details: sorry. I would expect the compiler to match the >parameter
> >size and type to locate the proper procedure. So, the getName in the vendor
> >service program expects a 5/0 number, the >getName in the G/L module expects
> >a 12/0 number and the getName procedure in the Inventory module expects a 10
> >character >parameter. I hope that helps explain what I was thinking about.
>
> >And yes, I realise that it is very possible that ther would STILL be a
> >problem if the Customer number, Item number and Vendor >numbers were all
> >numeric 5/0. How would the overloading work then? It wouldn't. But I was
> >just trying to show that the concept of >overloading procedures actually can
> >apply to real world business needs, and is not just a topic for lectures at
> >university.
I reiterate that I agree: we cannot tighten the signatures down to the
parameter size requirements. This would interfere with the ability to
pass by value, a very handy thing.
> Joel wrote:
> >I showed a perfectly legitimate and easy to understand example considering
> >dates:
> >
> >monthString = getMonth( dateField );
> >monthString = getMonth( timestampField );
> >monthNumber = getMonth( dateField );
> >monthNumber = getMonth( timestampField );
> >
> >Based on name, parameter list, and return value there are FOUR distinct
> >signatures here. To implement this using current >technologies you would
> >need four distinct procedures:
> >monthString = getMonthStringFromDate( dateField );
> >monthString = getMonthStringFromTimestamp( timestampField );
> >monthNumber = getMonthNumberFromDate( dateField );
> >monthNumber = getMonthNumberFromTimestamp( timestampField );
>
> Based on same books on java I have read, overloading is having defined
> multiple procedures with the same name, each receiving 0, 1 or more
> parameters and not necessarily of the same data type(s). Those procedures are
> always within the same object/class. I hope this is the correct concept.
It's hard to compare the way Java does it with the way RPG would do it,
definitely apples and oranges. In Java, and I assume most OO, ALL
procedure calls are object linked. Say I have a Person object: to use a
method in the person object I'm always refering to the object itself,
which tells Java which Class's method to use:
Person carel = new Person( "Carel" );
String lastName = carel.getLastName();
In RPG we have no such object relationship, so the signatures simply
have to be unique, again possibly assisted by qualified procedure calls.
> In the matter of RPG I may see a function of overloading procedures in
> retrieving a record via a service programme, in which each procedure (with
> different parameters) reads from a different LF on that file. Procedure names
> would have proper names like GetItem, GetCustumer. I do not like having to
> retrieve one single value this way (not like the get- and set-functions in
> the EJB-standard): there are some exceptions, of course.
>
Sure, great example!
recordDS = readMyFile( numericKey );
recordDS = readMyFile( stringKey );
recordDS = readMyFile( dateKey );
etc...
Assuming unique keys this would return the record into the datastructure
so that you wouldn't have to use individual gets and sets.
> To extend on Joel's example: you can also define the procedure:
> monthString = getMonth( );
> monthNumber = getMonth( );
You can accomplish this today with *nopass. I do so frequently because
it really enhances the flexibility of a procedure.
> This requires the return of a default value, based either on job date or on
> system date. That is a business rule, set by the user. It should not be
> hardcoded within the procedure. I think, this is an (important) issue, too.
I think this is kind of a non-issue. You could easily incorporate a
standard default, as long as it is well documented, or use some kind of
database driven user configuration to establish "flexible" defaults.
> How are you going to prototype those procedures? Are the parameters passed by
> reference or by value? The data types on the parm list are already defined.
> But the programme at run-time (not the compiler) has to determine which
> procedure to execute. And with two different data types for the return
> variable you may get problems. What will the programme check first: the
> incoming parms or the return parm? When will the check on the return parm be
> resolved: at the call or at the end of the procedure?
Hans made some excellent points about the problems with allowing
different return types. I have recanted and am willing to accept this
going in: the rest also wouldn't need to be changed from today's
approach. And in any case the compiler will have all the information at
compile time to determine the course of action. There is no way I know
of to change a variable type dynamically at run-time.
> I know these are technical questions, to which the compiler team has to find
> the answer, and we, programmers, should not be bothered with. Some of us only
> hope it will be possible, as it is possible in some OO-languages (and I do
> not think the difference between OO and procedural languages is an issue
> here).
I agree, this is not an OO vs. Procedural issue.
> But then, I would have thought there was a (limited) way of overloading in
> RPG: using *OMIT and *NOPASS on the prototype and checking with %PARMS and
> the inbound CEE-API's within the procedure.
No, not real overloading. You can certainly add flexibility to a
procedure by using optional parameters and an established rule pattern,
but the signature is always the same regardless of which parameters you
send or not. And if you have 3 *nopass options and only want the third
one you still have to use the first 2.
In fact, having procedure overloading would replace most of, if not all,
the need for *nopass. I don't use *OMIT so I can't say about that one.
> Joel also wrote:
> >You say this doesn't show a business case? In all four of these procedures
> >the logic is essentially identical, so what you are
> >suggesting is that having four copies of the same essential logic is somehow
> >better than having a single set of logic with four entry
> >methods. From a maintenance standpoint I'd rather have one piece of code to
> >maintain rather than four.
>
> I do not agree with you here: jt is right when he states overloading is not a
> business case; it is a case of development, design, coding.
If that is true, then using ILE vs. OPM, or Java vs. RPG is not a
business case either. The technology is not the business case. I
assumed that what jt meant was that there was no practical reason for us
as developers to use procedure overloading and I was trying to show an
example the does show its practicallity.
> And I think you contradict yourself or changed the argument: either you
> define 4 prototypes and 1 procedure with 4 PI to receive the parms, or you
> defined 4 prototypes and 4 procedures to deal with the incoming parms? The
> samples of java code I saw some years ago, using overloading, had multiple
> procedures with the same name and different PI's.
I probably failed to use the right terminology, I was thinking of a set
of procedures in a program/serviceprogram like methods in a Class, I
should probably not used the term procedures.
To clarify, by virtue of their existence 4PIs require 4 procedures: you
cannot, nor should you be able to, have 4 Prototypes for 1 PI. (This
would defeat the entire purpose of prototyping.) But in most cases
these procedures would only handle what you suggested, setting up the
parms for the main logic. Hans mentioned something about needing 4
procedures to match the 4 entry methods. His perspective is similar to
implementing interfaces in Java, where you define the interface but not
the logic. I was thinking more along the lines of a module being able
to receive multiple *ENTRY blocks, adjusting the incoming parms (so we
do define SOME logic unlike sheer interfaces), and then calling the core
logic:
<psuedo-code>
* Entry 1
p getMonth b
d getMonth pi 2 0
d dateIn d
/free
return process( dateIn );
/end-free
p getMonth e
* Entry 2
p getMonth b
d getMonth pi 2 0
d timestamp z
/free
return process( %date( timestamp ) );
/end-free
p getMonth e
* Entry 3
p getMonth b
d getMonth pi 2 0
d string 10a
/free
return process( createDate( string ) );
/end-free
p getMonth e
* Entry 4
p getMonth b
d getMonth pi 2 0
d numeric 8 0
/free
return process( createDate( numeric ) );
/end-free
p getMonth e
* Process Main Logic
p process b
d process pi 2 0
d dateIn d
/free
return %subdt( dateIn : *m );
/end-free
p process e
</psuedocode>
Yes, on a technical basis I am coding individual procedures for multiple
interfaces, but I'm not replicating the core logic. And what Hans is
suggesting is not diametrically opposed to this approach either: there
is nothing preventing me from writing specialized logic for any of these
procedures.
Naturally this could be a lot more complex. It is true that this can be
simulated today with one exception: you cannot use the getMonth() name
more than once. In fact, as I mentioned in an earlier post, I have done
so quite a bit, I'm not waiting with baited breath for IBM to provide
this feature, but I will be endlessly thankful once they do.
> Regards,
> Carel Teijgeler.
Thank you Carel for the nice discussion points,
Joel
http://www.rpgnext.com
As an Amazon Associate we earn from qualifying purchases.
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.
