RE: Multi Occurrence Data Structure returned from a procedure

>> %lookup() or a similar method?  That would have performance implications,
>> and frankly I don't see what it's buying you.

Simply allowing the user to assign a name that means something to them. For 
example, "cFINAL_TOTALS_ARRAY" and yes it does have to be looked up but I don't 
see much of a performance issue considering on the average you have probably 
one or two open paths or arrays open, etc. Just seems cleaner to me. 

All of this comes out of my experience implementing service programs for other 
programmers and before that standard dynamic programs. My experience was that 
if there was a way to screw it up, they would do it. I just tired of hearing, 
"You're program doesn't work" and then going in and finding out they had done 
that one thing they shouldn't of so I started thinking defensively. I had to 
always do that but I had to push it up to a new level. I had to figure out a 
way to do standard error handling that did not depend on the programmer because 
if it did they wouldn't do it, etc, etc. 

I kept finding out again and again that the problem was that people had 
implemented things wrong or done completely silly stuff so make it simple and 
easy and error check everything and assume nothing because if I started hearing 
the cries, "You're program doesn't work". Implementing general purpose service 
programs is a lot of work. You just can't take anything for granted or at least 
that was my experience. It still doesn't stop people from doing silly stuff but 
at least they get back a meaningful message like "Order not created" or 
something like that instead of "Invalid pointer". The nice thing about working 
in ILE RPG is that it lets you design code to makes that possible. 

How many times have you heard back from some of your standard libraries that 
they don't work because somebody forgot the %Addr() around a variable? I work 
like a dog trying to build standard functions that are as bullet proof as 
possible but I think it is worth it or at least I hope so but like Bob said in 
a previous post, people in general just don't use standard functions on the 
AS/400. They just reimplement in each program. 

I do like your approach in building the object(?) and object destroy. Makes it 
easy to read. Seems we are both trying to make it easier. Just some 
disagreements about how best to implement. Still just don't see the need for 
returning a pointer. Return something that can be validated. An invalid pointer 
is going to give you nothing but a "invalid pointer" error and what does that 
mean? 

Thanks for the feedback. 
 
-----Original Message-----
From: Scott Klement [mailto:rpg400-l@xxxxxxxxxxxxxxxx]
Sent: Wednesday, July 06, 2005 1:56 PM
To: RPG programming on the AS400 / iSeries
Subject: RE: Multi Occurrence Data Structure returned from a procedure




> 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!!!