Re: Variable length MODS

[boldt@xxxxxxxxxx]

Jon wrote:
>There is nothing wrong with your thinking as far as it goes.  It just
>doesn't extend into taking RPG history into account.
>
>Remember that pointers etc. were retrofitted to RPG relatively late in its
>life.  RPG applies upper bound checking to arrays and MODS based on the
>size specified.  When BASED structures were introduced (for better or
>worse) no change was made to the code generation in this area.  At some
>point in the future one hopes that the compiler folks (are you listening
>Hans and Barbara?) will allow us to specify the size of a based array etc.
>via a variable.  If they make the storage reallocate itself magically
>whenever I change that variable then that would be nice too - but I could
>live wit just being able to specify the current size.
>
>Until such time as they change the compiler - think of it this way - the
>value for DIM is a sanity check when used with based storage - I set it to
>a value that says "when it gets this big I must be looping".  Then
>implement your own upper bound check the way you have to (or should do) in
>many other languages.

Well, I, for one, am following this discussion.  As you know, dynamic
arrays and MODS's came in at 10th place in the 2001 enhancement
survey.  The 1st 9 items already cost $98.  In other words, it was
voted just past the $100 cutoff.

The big problem is designing exactly how this type of function should
work.  For example, if you pass a dynamic array as a procedure parm,
how should the limit value be handled?  Should it be part of the data
being passed?  Or must the limit be handled separately in every
procedure that uses the array?  Each choice has its advantages and
costs which need balancing out.  Or perhaps there are easier
alternatives, such as the "number of elements" parameter on the new
%LOOKUPxx built-ins.  If we extend the SORTA opcode and the %XFOOT BIF
the same way, would that satisfy 80% (more or less) of the coding
needs for dynamic arrays?  Those could be designed and implemented for
fairly low cost in comparison to other alternatives.

(To be honest, though, the $100 cutoff is really just a rough
guideline.  We're considering implementing a few items from below that
line where they fit nicely with other chosen items.  One item, in
particular, was voted fairly low, but really goes hand-in-hand with
another item in the top nine.  Both items together cost much less than
the sum of both priced separately and together satisfy a long-standing
requirement (in addition to their own merits).  I'm very tempted to post
some sample RPG code I actually have running here in the lab, but it's
still way too early to talk about the post-V5R1 future.  (Maybe I
shouldn't even post such "teasers", but I feel mischievous this
morning!))

Cheers!  Hans

Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.com

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