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



Personally i avoid MODS now in preference to arrays...do i still use
MODS...yes but as Adam suggests use what works best for you. the
performance difference can be measured in nano-seconds...not really worth
consideration IMO. but as always YMMV

Thanks,
Tommy Holden



Adam Glauser <adamglauser@xxxxxxxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
12/13/2007 09:22 AM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>


To
rpg400-l@xxxxxxxxxxxx
cc

Subject
Re: Multi- Occurrence Data Structure






Ken Sims wrote:
[W]hy have to bother to put the array index on the access to every
field
in the data structure?

Adam Glauser wrote:
Clarity - see Jon Paris' earlier message for an example.

Ken Sims wrote:
If you're talking about his example of comparing the values of a
subfield in two different occurrences, that is using functionality
availablle only to array structures, whereas I said specifically ..

If you're *NOT* using functionality that is available only to array
data structures
(emphasis added)

so his example is irrelevant to what I'm saying.

I guess I don't see comparing subfields of different instances as
special functionality, just something that should be easy to do.

Ken Sims wrote:
And if the index is a variable, it has to be
resolved and checked every time to make sure it is within the allowed
range. With the regular MODS, resolution and checking only has to be
done when the occurrence is set. After that it's just like using a
single occurrence data structure, which is better for performance.

Adam Glauser wrote:
"Premature optimization is the root of all evil." - Donald Knuth

Ken Sims wrote:
I don't see that that quote has anything to do with what I'm saying.

I'm not advocating some esoteric optimization method, I'm just taking
advantage of a straight forward programming technique.

My point is that this is not a strong argument for using MODS. The
potential performance gain is likely to be minuscule at best in almost
every situation. If you have a a specific case where you think that
resolving the index variable will be a bottleneck, by all means use a
MODS defensively. I just don't think that such situations are frequent
enough to say "use MODS whenever possible because they perform better".


As a real life example, in a program that I'm currently writing, I
originally coded a data structure as an array data structure. As I
was putting the array index on the statements loading the various
sub-fields, I thought "Why the hell am I doing this? I'm not going to
be sorting it or doing anything else which needs the array
functionality." So I changed it to a MODS.

To me, the extra keystrokes are a small price to pay for the enhanced
clarity and more standard syntax. I guess that's just the way I roll.
I think this point is just a case of preferred style, and there's really
no point arguing that.

On the whole, I'm not suggesting that MODS are bad, or that they should
never be used. This thread started because Srinivas asked what MODS are
and in which situations they ought to be used. In my opinion, there is
no case to be made for MODS usage by someone to whom they are not
already preferred, as long as they are on a release where array DS
functionality is a superset of MODS functionality.

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.