RE: Multi Occurrence Data Structure returned from a procedure

[Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>]

> I would be one of those people who think that you should return a 
> numeric handle. Lately I have taken that one level further in IFS and 
> that is to have the user assign a name to the open.
I don't understand.  How does a name help you? Are you somehow translating 
that name into a space in memory in the service program?  Maybe using 
%lookup() or a similar method?  That would have performance implications, 
and frankly I don't see what it's buying you.
They can name the variable something meaningful to them and use that name 
if they want.  This gives both performance and easy-to-read code.
> Some string constant and then refer to the open through that name. I 
> have found that the numeric number getting confusing to users of the 
> function but I would definitely feel there is no reason to return a 
> pointer in this case.
The pointer just makes the code in the service program simpler. Otherwise 
you need a routine that checks for an empty data structure in the array 
that the number indexes, and you need to have a routine that cleans it up, 
and so on...  the pointer is just easier.
I agree that the numeric one is better for "hiding" the information, but, 
for me it's not usually worth the tiny risk of the user 
reverse-engineering the memory that I point to.
> Just to easy for the user to screw it up and all that can be hidden. In 
> your example, could you not pass the order identifier to the new 
> function and refer to the order from that.
Depends on what the code does.  Frequently I have additional information 
that I want to keep private in the service program.  I want to keep this 
information in-between calls, but not give the caller access to it.  I 
could use an array of data structures, MODS, etc, but it creates 
additional complexity and limits the number of concurrent objects that I 
have loaded (since an array always has a fixed size).  Plus, I end up with 
an array of DSes that takes up the full amount of memory, even if i'm only 
using one or two elements.  Granted, I could use a dynamic array, but that 
adds even more complexity.  Even if I decided to go that route, and use 
%LOOKUP or bsearch() to associate an order id with the "private data" data 
structure, then I'd still have to deal with the extra CPU time involved in 
searching the array of the order ID, which with a LOT of calls, reduces 
performance significantly.
So, I prefer to return a pointer.  That way, it always uses the right 
amount of memory, I have no problem with the number of instances I can 
create, I have no performance problems, the code is much simpler...  etc.
Of course, the caller doesn't ahve to know that it's dealing with a 
pointer.  I'll often have the following in my /COPY file with the 
prototypes:
     D ORDER_HANDLE    s               *   based(Template)

When the caller wants to use my code, they'd do something like this:

     D CurOrd          s                   like(ORDER_HANDLE)

So that gives them their own (meaningful) variable name, and they don't 
even know (necessarily) that they're working with a pointer.  They're then 
able to call my service program with:
       CurOrd = Order_new();

and a new instance of the "order object" has been created.  When they're 
done, they do:
      Order_destroy(CurOrd);

And the memory is freed to the system.  While they've got a valid order 
object, they can do:
     Order_load(CurOrd: '12345');

     Order_addItem(CurOrd: ItemNo: Quantity: Price);

And whatever else.

> In this example, also, it would seem that the result would be an order 
> number. Wouldn't that be preferable to returning the pointer? Seems like 
> the pointer is not really needed.
The result isn't an order number, it's an order OBJECT. If it was an order 
number, I definitely wouldn't use a pointer!!!