RE: Multi Occurrence Data Structure returned from a procedure -- RPG400-L

I would be one of those people who think that you should return anumeric handle. Lately I have taken that one level further in IFS andthat is to have the user assign a name to the open.

I don't understand. How does a name help you? Are you somehow translatingthat 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 nameif they want. This gives both performance and easy-to-read code.

Some string constant and then refer to the open through that name. Ihave found that the numeric number getting confusing to users of thefunction but I would definitely feel there is no reason to return apointer in this case.

The pointer just makes the code in the service program simpler. Otherwiseyou need a routine that checks for an empty data structure in the arraythat 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 userreverse-engineering the memory that I point to.

Just to easy for the user to screw it up and all that can be hidden. Inyour example, could you not pass the order identifier to the newfunction and refer to the order from that.

Depends on what the code does. Frequently I have additional informationthat I want to keep private in the service program. I want to keep thisinformation in-between calls, but not give the caller access to it. Icould use an array of data structures, MODS, etc, but it createsadditional complexity and limits the number of concurrent objects that Ihave loaded (since an array always has a fixed size). Plus, I end up withan array of DSes that takes up the full amount of memory, even if i'm onlyusing one or two elements. Granted, I could use a dynamic array, but thatadds 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" datastructure, then I'd still have to deal with the extra CPU time involved insearching the array of the order ID, which with a LOT of calls, reducesperformance significantly.

So, I prefer to return a pointer. That way, it always uses the rightamount of memory, I have no problem with the number of instances I cancreate, 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 apointer. I'll often have the following in my /COPY file with theprototypes:


     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'teven know (necessarily) that they're working with a pointer. They're thenable to call my service program with:


       CurOrd = Order_new();

and a new instance of the "order object" has been created. When they'redone, they do:


      Order_destroy(CurOrd);

And the memory is freed to the system. While they've got a valid orderobject, 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 ordernumber. Wouldn't that be preferable to returning the pointer? Seems likethe pointer is not really needed.

The result isn't an order number, it's an order OBJECT. If it was an ordernumber, I definitely wouldn't use a pointer!!!