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



Why should we nitpick about something that may add a few
seconds to our procedure's runtime instead of using
something that is more intuitive.

I agree with you.

But, I want to qualify that and say that it depends on the purpose of the procedure. Sometimes a return value is more intuitive, and sometimes it isn't. Sometimes performance is critical, and sometimes it isn't.

Unfortunately, I've seen quite a few people who swear that it's "wrong" to return data via a parameter. They use return values for anything they return, often making their routines cumbersome to use, frightfully slow, and a burden to the company that has to support them.

There is no crystal clear rule that says "always" return a value, or "always" pass parameters. Instead, there are tradeoffs between elegance, functionality and performance. Each procedure needs to be evaluated individually based on what it's role is to be.

In this particular thread, it started with a discussion of one particular subprocedure. Here's a link to the start:
http://archive.midrange.com/rpg400-l/200604/msg00652.html

Here's the subprocedure that he was looking for advice about:

D  ReasonDS       DS          5400
D   @RsnCode                     2A   Dim(200)
D   @Charge                      9  2 Dim(200)
D   @Weight                      9  0 Dim(200)
D   @Units                       7  0 Dim(200)


D BilUtil_getReasonTotals...
D                 PR                  LikeDS(ReasonDS)
D @prPlant_                      3  0 Value
D @prBillTo_                     5  0 Value
D @prBillDate_                    D   Value
D @prInvoice_                    5  0 Value


This is a situation where I see absolutely no value to returning the DS as a return value. It hurts performance, wastes resources, and for what? Do you think it adds a lot of value for this DS to be usable in an expression? I don't. Most likely, any expression that uses it will just assign it to another copy of the DS. It'd make more sense to operate on that final copy of the DS in the first place, which is why it'd make more sense for it to be a reference parm.

That's why I gave that advice, and explained the disadvantages of returning it as a return value. I was not intending to say that return values should never be used -- what I did intend to say was that *IF* performance is critical, you should avoid return values larger than 30-40 bytes.

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.