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


  • Subject: Re: Procedure Problem
  • From: Jim Langston <jlangston@xxxxxxxxxxxxxxxx>
  • Date: Thu, 23 Dec 1999 09:33:59 -0800
  • Organization: Conex Global Logistics Services, Inc.

Actually, yes, I do abhor the AS/400 API's that require
you to pass a receiver variable as the first parameter.
That is why I was so glad when RPG at least came up
with real functions that returned variables.

Today we are using Procedure Interfaces, and we will
in the future, but soon we will start doing the #include thing
and put all the Procedure Interfaces in a header type file
and just /COPY it into our programs.  And we, as the
programmers, won't actually see the Procedure Interface
unless we go into the copied file (I'm going to call it a
header file from now on) and look at the parameters.

When I use a new function or subroutine in some language
I am actually usually rather quick about it.  I find the
documentation on it however I can (help, a book, reference
manual) and I take note of the parameters, what variable
types they need to be, what data I am supposed to be
passing them and what my return value is.  Then I breeze
through the text on the function to see that it is actually
going to do what I am wanting it to do.

Then I write a stub program, pass it the parameters, call
it and see if my return variable is what I expected it to be.
If all goes well, I then start using it.

But, with my imaginary function StringLength, if I am looking
for a function to return the trimed length of a string and I find
it, and read on it, and just don't happen to notice that it also
changes the passed variable that's where my bug enters
later on when I use the same function I have always used but
happen to do something with the parameter I passed anyway.

We know a function returns variables.  That's what a function
does.  We know a subroutine changes data, that's what a
subroutine does.  The parameters being passed to either should
just tell the function or subroutine how to do it's job, they shouldn't
be used the other way around.

I do acknowledge, however, that sometimes we can just not get
around it.  Such as wanting to return 2 variables from a function
in a language that does not allow us to pass a structure.  But I
think it should be kept to a bare minimum whenever possible.

Regards,

Jim Langston


John Taylor wrote:

> <SNIP>
> Other good examples of this technique are the many AS/400 API's that require
> you to pass a receiver variable as the first parameter. Do you abhor those
> as well?

<SNIP>

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

Replies:

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.